Modelling Users, Groups, Portfolios and Media using an MVC Approach

Question

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 which stores all the User Details, I have a Groups Table which stores all the Group details, the relation between these 2 models is has and belongs to many, then I have a group_portfolios table which stores all portfolios belonging to a group and a user_portfolio table which stores all portfolio information related to a user. A user can have multiple portfolios A group can have multiple portfolios A user can have many media A group can have many Media

I have separated the functionality for media associated with users and groups, My question would be,

1) am I thinking in the correct way in terms of modelling an MVC application?
2) Since I am separating the the functionality for users and groups I am ending up with 2 tables for all information related to them e.g media and portfolio. Does this cause any redundancy and performance related issues, especially when searching for a portfolio and so on?
3) Will this be able to scale when I want to add more features later on?
4) Is there a better way to model the system?

Thank You

Answer 1

I have used RoR and Castle, not CakePHP so I will talk in general terms.

1: What you have been doing and what you should continue to do is called 'Domain Modelling' - MVC is great for this as your models become representations of objects in your domain model

2: You could change the portfolio and media models to instead of referencing the id of its parent, you have an 'ObjectId' and 'ObjectType' - ObjectId is the id of the parent and ObjectType is the type. You will not be able to auto-wire the relationships but can instead do so with custom code, so to get all media for a User it becomes

select * from Media where ObjectId = [userid] and ObjectType = 'User'

instead of

select * from UserMedia where UserId = [userid]

3: yes, it's a scalable design. remember to push as much model-specific work into the models themselves (or repositories) to make it 'just work'

4: Maybe, but you never get a 'perfect' system. MVC is great and your design seems solid for a simple social network. You will no doubt add things like posts/comments etc.

Answer 2

You could use a single media and a single portfolio table. Add an extra field that tells you whether it belongs to a User or a Group. Then, don't add the $belongsTo attribute to your model but use the bindModel method to dynamically attach the correct model.

Alternatively you chould also use UUIDs (mysql: varchar 36) instead of integers for your IDs. UUIDs never collide. So, you could make Portfolio and Media belongsTo User and group, using the same field. This works because there never will be a User that has the same ID as a Group when you use UUIDs. Example:

class Media {
    $belongsTo = array(
        'User' => array('foreignKey' => 'parent_id'),
        'Group' => array('foreignKey' => 'parent_id'),
    );
}

The former is technically more correct. The latter is easier to implement and you may not like the longer URLs that the long UUIDs create.

Edit: To address your comment about uniqueness, UUIDs are designed to be globally unique. That is, not only will you not have duplicates inside your own database, but there should not be any duplicates in the world. Anywhere.

See this Wikipedia article about the probability of dupliactes using UUID. The short story: After generating 70,000 billion UUID's the probability of having just even one duplicate is 4 in 10 billion. You have a better chance of being struck by lightning twice on the same day :-)

Answer 3

In adition to what Sander Marechal said about GUIDs, you might want to consider the PolymorphicBehavior for your Media model. It will speed up your app and you won't have to worry about broken relations at any time.

About your design question..we don't really know your app, and can't provide any detailed answers. No, it's a lie: I don't want to provide a potentially wrong answer.

However, I can give you some tips. :) You should sit down and draw your model relations and think how will they be used in real life. Then see if there is anything missing, or maybe there is too much of something. Optimize and minimize data returned from your database. Crucial concept here is simplicity. If it's not as simple as possible, it's wrong.

If you go half way through and realize you've made a design mistake - admit you've made a design mistake and fix it! Sometimes you can't predict everything and there is no shame in it (well, as long as you learn something..).