I am building a cms using codeigniter mvc framework (but this question applies to any mvc) and mysql. I have multiple controllers that route different pages (e.g. home, contact, blog, etc). All the pages have something in common: there is a title, description, and body for each post. So it sounds silly to create a table for each page when they contain pretty much the same content. So I decided to create one table called posts. But my problem occurred when I want to render specific posts on different parts of different pages. I thought that creating a table called "zones" which looks something like this:
id title description
1 home main_content
2 home sidebar
3 contact main_content
4 contact sidebar
id title description zone_id
1 hello hello world 1
would allow me to query like this:
SELECT * FROM posts INNER JOIN zones ON posts.zone_id = zones.id;
In another forum I was told:
"First of all the MVC Pattern is designed to decouple between the three layers (model / view / controller). I would say that if the additional field you want to add to the database will specify which is the view that should be used, it's a clear violation of the decoupling principles in mvc(model should not store controller logic)."
But then how else can I filter on what posts to display on page?
And if my initial technique does not "violate" MVC, I have another concern. This page:
seems to call my "fixed data model" inflexible and its "template data model" more flexible, just because its model contains a contentnode table that stores the posts and a template table. But honestly I see no need for those additional tables to make the page more flexible. Does anyone agree?
It might be worth downloading DNN/Sitefinity/Umbraco/Kentico and see how they setup their database structures. The common thread is creating a concept of a control, or template (like an HTML control, RSS control, etc), then creating "instances" of those controls in the database. You can then move "instances" into what you have described as "zone"s.
Seriously though, this problem has been solved many, many, many times. Now days I would need a really good reason not to start with something off the shelf (or at least borrow their implementation ideas) when approaching a new project.