I'm looking for some db design help. I have an existing application that I'd like to add the following features to:
- Support the concept of a Site Blog
- Allow members to each have their own blog
- Admins can post to the Site Blog,
- Members can post to their own member blog
Since a Site can only have one blog, and each member can only have one blog. I don't think I need a Blog table. Instead I'll just hang a couple of columns off the Sites and Users tables for blog_name, blog_tagline, or something.
My question is: Should I use one table for posts or should I use 2 tables (site_posts and member_posts) instead.
If I use 1 table, I can easily have a type column (Site or Member) and a content_id column pointing to related parent record (site or member). But, I'm thinking what is the best way to do this in terms of resources and controllers. If I have 1 table then I'd have one controller Posts. But, based on a user's role they'd be updating either Site posts or Members posts. This seems a little messy, always checking a user's role just to update a resource.
So, I'm leaning towards 2 resources (and 2 tables), so I know that Members are always working on member_posts and admins on site_posts.
Anyone have any thoughts on this design or see any issues?
Thanks.