Multiple-table Models
Moderator: General Moderators
-
thinsoldier
- Forum Contributor
- Posts: 367
- Joined: Fri Jul 20, 2007 11:29 am
- Contact:
Multiple-table Models
If I have have a giant form that inserts or updates data across 5 tables
should I have my 5 database table classes within my controller?
Or should I make another model that represents the overall item of interest and contains the 5 db table classes?
Should I be using transactions when updating those 5 tables?
should I have my 5 database table classes within my controller?
Or should I make another model that represents the overall item of interest and contains the 5 db table classes?
Should I be using transactions when updating those 5 tables?
Warning: I have no idea what I'm talking about.
- AbraCadaver
- DevNet Master
- Posts: 2572
- Joined: Mon Feb 24, 2003 10:12 am
- Location: The Republic of Texas
- Contact:
Re: Multiple-table Models
I guess you should have 5 models that represent each table and perform validation, relations and business logic. Then the controller should submit the relevant data to the model(s).
mysql_function(): WARNING: This extension is deprecated as of PHP 5.5.0, and will be removed in the future. Instead, the MySQLi or PDO_MySQLextension should be used. See also MySQL: choosing an API guide and related FAQ for more information.
- Jonah Bron
- DevNet Master
- Posts: 2764
- Joined: Thu Mar 15, 2007 6:28 pm
- Location: Redding, California
Re: Multiple-table Models
Not necessarily: a model doesn't ways directly correspond to a table, especially with complex data. But it certainly may in this case.AbraCadaver wrote:I guess you should have 5 models that represent each table and perform validation, relations and business logic. Then the controller should submit the relevant data to the model(s).
Could you post the table schemas?
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Multiple-table Models
I agree that it sounds like one Model class, given that the form is one business operation. It is possible that it might be more Models than one depending on the design of your database, but probably not one class per table (those would be Datasource Layer objects, not Doman Layer objects).
Yes for transactions.
Yes for transactions.
(#10850)
- AbraCadaver
- DevNet Master
- Posts: 2572
- Joined: Mon Feb 24, 2003 10:12 am
- Location: The Republic of Texas
- Contact:
Re: Multiple-table Models
Well, I made some assumptions based upon some real world examples since the OP didn't elaborate on the type of data or the application. Take a blog post for example: you may have a Posts table, a related Categories table, a related Users table, a related Tags table and maybe more. Is anyone suggesting a single model for a blog post that represents all of these tables and their relationships, validation and business logic? And then separate models for each of the tables so that you can manage categories, users and tags separately?
Last edited by AbraCadaver on Thu Jul 14, 2011 10:02 pm, edited 1 time in total.
mysql_function(): WARNING: This extension is deprecated as of PHP 5.5.0, and will be removed in the future. Instead, the MySQLi or PDO_MySQLextension should be used. See also MySQL: choosing an API guide and related FAQ for more information.
- Jonah Bron
- DevNet Master
- Posts: 2764
- Joined: Thu Mar 15, 2007 6:28 pm
- Location: Redding, California
Re: Multiple-table Models
I didn't mean to imply that you didn't know that, just clarifying for the OPAbraCadaver wrote:Well, I made some assumptions based upon some real world examples since the OP didn't elaborate on the type of data or the application
- AbraCadaver
- DevNet Master
- Posts: 2572
- Joined: Mon Feb 24, 2003 10:12 am
- Location: The Republic of Texas
- Contact:
Re: Multiple-table Models
Sorry, I should have quoted something. I was probably responding more to Christopher's "one Model class".Jonah Bron wrote:I didn't mean to imply that you didn't know that, just clarifying for the OPAbraCadaver wrote:Well, I made some assumptions based upon some real world examples since the OP didn't elaborate on the type of data or the application
So just to clarify, maybe Christopher and I are on the same page (not sure). In my simple example, I would have a Posts model that took care of all of the Posts table stuff as well as relating and updating the other tables since we know the relations and they are defined. So for that one operation there is only one model, but it would make use of the other models since they have their independent uses. So we still need models for the individual entities that can be managed independent of the blog posts (tags, categories, etc.). That was my point with the multiple models.
mysql_function(): WARNING: This extension is deprecated as of PHP 5.5.0, and will be removed in the future. Instead, the MySQLi or PDO_MySQLextension should be used. See also MySQL: choosing an API guide and related FAQ for more information.
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Re: Multiple-table Models
Interesting question one I still struggle with occasionally. Personally I would implement each as a separate distinct model, with it's own business logic, validations, etc. However I would also implement a facade/strategy to act as a single point of contact for the given controller - if more than one model was required that is.Or should I make another model that represents the overall item of interest and contains the 5 db table classes?
This is where I think more clarity is required - at least for me. If the model reflects only a single table, and some higher-level abstract model acts as a coordinator between various entity models and the controller:action. I often considered the latter the domain model and individual as entity models. In DDD parlance, I think this may be analogous to an aggregate root?!?
I personally/professionally appreciate the simplicity of implementing models on a per table basis, but when schema are complex enough to require cross-table associations I would prefer to find a way to connect those objects using a more abstract model object. Relying on VIEWS to emulate single table sources and perform complex SELECTS as a separate object - I think this would be analogous to DDD service.
Interesting conversation, keep er' going
Cheers,
Alex
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Multiple-table Models
As I said about, there is a distinction between Domain Model objects and Datasource layer objects. However, the term Model applies to a broad range of things in web development.AbraCadaver wrote:So just to clarify, maybe Christopher and I are on the same page (not sure). In my simple example, I would have a Posts model that took care of all of the Posts table stuff as well as relating and updating the other tables since we know the relations and they are defined. So for that one operation there is only one model, but it would make use of the other models since they have their independent uses. So we still need models for the individual entities that can be managed independent of the blog posts (tags, categories, etc.). That was my point with the multiple models.
One goal of a Model object is that it abstracts the underlying Datasource to give you flexibility to change things like the database schema without affecting the application. So a Model object might have a method like $product->findAllSaleItems() which internally might call a Datasource object like $db->select("price < list_price"). Later you could change that call to $db->select("on_sale='yes'") but the Model's $product->findAllSaleItems() method would be unchanged.
So when I hear "one class per table" my thought is that those object tend to be Gateway or ActiveRecord like objects -- and not really Domain objects -- and hence not Models.
(#10850)
- Jonah Bron
- DevNet Master
- Posts: 2764
- Joined: Thu Mar 15, 2007 6:28 pm
- Location: Redding, California
Re: Multiple-table Models
Excellent explanation, Christopher.
[via droidx]t
[via droidx]t