Database design with MVC framework

[johnmerlino]

Hey all,

I'm using mvc framework, where I use controllers for all my main views, such as home page, about us page, contact, etc. However, all the views contain something in common: the ability to create post, update post, delete post, edit post. So I use one model to handle this corresponding to one table called posts. This table contains all the content of the site. Now on different views, I want to render specific posts that relate to views. Currently my index method for all the controllers call the same find method:

public static function find($param){
			$self = get_instance(); 
			if($param === '*' || $param === 'all'){
				$resources = $self->db->get('posts');  
 				return $resources->result(); 
			}
			return null;
		}

With this find method, all of my views will render all of the posts. So I am wondering should I create another field in the database called page_id, which corresponds to a controller. So when the user invokes index method of home controller, I pass in an additional parameter like '1' and query the database to select all records where the page_id is equal to 1. Is this effective or is there a better approach to restrict posts that display in a content management system?

Thanks for response.

[Fumigator]

So your "find" method is returning all posts, and you want to filter posts based on page. In my mind, it's bad design to store in your database a page ID like you're thinking of doing. It's better to filter logically, either before you call "find" or after. It makes sense to me to send arguments to the "find" method to filter the results.

By filtering logically I mean use keywords, not page IDs. This gives you the flexibility to build keyword lists that put the same posts in multiple filter buckets as appropriate.