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

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 🙂