Modeling Users, Groups, Portfolios and Media Using an MVC Approach
I am creating a simple design for a social networking site using the MVC paradigm (in CakePHP) for a project, I have a table called "Users" that stores all user data, I have a groups table that stores all data Groups, the relation between the two models has and belongs to many, then I have a group_portfolios table that stores all portfolios owned by a group and a user_portfolio table that stores all portfolio information associated with a user. User can have multiple portfolios Group can have multiple portfolios User can have multiple media Group can have multiple media
I have separated the functionality for media related to users and groups, my question would be,
1) Am I thinking correctly about modeling an MVC application?
2) Since I split the functionality for users and groups, I end up with 2 tables for all information related to them, such as media and portfolio. This creates redundancy and performance issues, especially when looking for a portfolio, etc.
3) Will it be scalable when I want to add more functionality later?
4) Is there a better way to model the system?
thanks
a source to share
You can use one medium and one portfolio table. Add an additional field to indicate whether it belongs to a user or a group. Then don't add the $ attribTo attribute to your model, but use the bindModel method to dynamically attach the correct model.
Alternatively, you can also use UUIDs (mysql: varchar 36) instead of integers for your ids. UUIDs never collide. So you can make the Portfolio and Media group belong to the User group and by using the same field. This works because there will never be a user that has the same ID as the group when you use the UUID. Example:
class Media {
$belongsTo = array(
'User' => array('foreignKey' => 'parent_id'),
'Group' => array('foreignKey' => 'parent_id'),
);
}
The first is technically more correct. The latter is easier to implement and you may not like longer URLs that generate long UUIDs.
Change: . To answer your comments about uniqueness, UUIDs are designed to be globally unique. That is, not only will you not have duplicates inside your own database, but there shouldn't be any duplicates in the world. Anywhere.
See this Wikipedia article on the possibility of duplication using UUIDs. Brief history: after generating 70,000 billion UUIDs, the probability of having exactly one duplicate is 4 in 10 billion. You have a better chance of being struck by lightning twice on the same day :-)
a source to share
In connection with what Sander Marechal said about GUIDs, you might consider PolymorphicBehavior for your media model. This will speed up your application so you don't have to worry about relationship breakdowns at any time.
About your design question .. we really don't know your app and can't provide detailed answers. No, that's a lie: I don't want to give a potentially wrong answer.
However, I can give you some tips. :) You should sit down and draw your model relationship and think about how it will be used in real life. Then see if there is something, or maybe too much of something. Optimizing and minimizing data returned from your database. The key concept here is simplicity. If it’s not that easy, it’s wrong.
If you go halfway and realize you made a design mistake, admit that you made a design mistake and fix it! Sometimes you cannot predict everything, and there is no shame in that (well, as long as you learn something ..).
a source to share
I used RoR and Castle, not CakePHP, so I'll be talking in general terms.
1: What you have been doing, and what you should continue to do, is called "Domain Modeling" - MVC is great for this, as your models become representations of objects in your domain model.
2: You can change portfolio and media models instead of referencing your parent's id, you have ObjectId and ObjectType. ObjectId is the parent identifier and ObjectType is the type. You won't be able to automatically bind the relationship, but instead you can do it with custom code, so to get all media for the user, it will become
select * from Media where ObjectId = [userid] and ObjectType = 'User'
instead
select * from UserMedia where UserId = [userid]
3: yes, it's a scalable design. don't forget to click on work with models the models themselves (or repositories) to make it "just work"
4: Maybe, but you will never get the "perfect" system. MVC is great and your design feels solid for a simple social network. You will surely add things like posts / comments, etc.
a source to share