Model Development

[eluser]UnforgiveNX[/eluser]
Hi all,

I'm trying to develop a model with CodeIgniter. I have three mysql tables; Users, Products and Comments. As you may imagine, users and products are stand-alone tables but comments table is related to users and product (who is commented and commented to which product).

I'm wondering what is the best practice to develop models.

Should I create
one model for each table, or
one model for each standalone table ?

I have seen some projects. For instance Dx_auth plugin uses seperate models for each database table (login_attempts, permissions, roles, ..). What if there would be only one "user" module?

What is the best practice?

Thank you

[eluser]Aken[/eluser]
I'm not 100% clear on what you're asking, but you should create any necessary models based on the actions you need to perform, not the specific databases they're for. Technically you can create a single model with all your necessary functions in there. But if you have a lot, you'll want to avoid that.

[eluser]BrianDHall[/eluser]
Not to be a single-issue-fanatic or a drum-banger for ORM, but its in this exact situation that I found it such a superior way of doing things.

Using Datamapper - OverZealous Extension for example, the best practice is as follows:

Each table has its own Model. Each model has any special functions unique to that table, such as add_product() in Product for example, or login() for Users.

In ORM terminology, your Comments table is considered as having a Many to Many relationship, while Products and Users have a One To Many relationship.

So then the practice is when setting this up, you create a join table for the use of your ORM system. For instance you'd have a join_comments_products table, and a join_comments_users table. Exact details: http://www.overzealous.com/dmz/pages/prefix.html

This sounds complicated, but after a few hours of tinkering the first time it becomes surprisingly simple. The payoff is from then on, the ORM system handles the rest.

So in the future you can have Users that have relations to Comments, Accounts, and Products that relate to Vendors and Manufacturors, and Vendors can make Comments, and what a huge mess that would be trying to manage yourself - but the ORM just handles it. Then you use simple get functions where you can pull all the comments relating to a certain product or vendor, or all the comments belonging to a certain user - and it's all in objects, so you don't have to think about the mess of foreign keys, join SQL syntax, half-dozen tables, and all that mind-numbing mess when all you wanted was a simple "What Other People Think About This Product/Vendor/Manufacturer" page.

It pays to think ahead of time and map out all the tables and relationships you need, but if you have to make changes it's rarely THAT big of a deal.

Before using it I said "ah phooey, who needs all that complicated crap - give me SQL syntax any day"...and now having used it just once I wouldn't want to be without it. So much I don't have to think about anymore, and I never did have to learn proper join syntax

[eluser]Nick Husher[/eluser]
You probably want to generate one model for each abstract object you think you'll be interacting with. So, in your case, three models.

Note that models can make use of other models, so you can use your Users and Products models to populate your Comments model data (and vice versa if you want to get all comments on a Product or all comments on a User).