there would be some jiggerypokery with the foreign keys... and probably some on-the-fly binding of models to get what you want...but it will be more expandable. You wont need to create a new transactions table for every new type of asset you create....
I've not ever done it, but i suppose you could build a behavior that manages this sort of thing magically for you.... leading to less recoding of things in the long term. it is pretty much a many-to-many relationship... (book hasmany transactions, transactions hasmany users)...i suppose you could do it with HABTM... but i've not given it a lot of thought given that its almost 11pm and I'm tired :) Have a play with it and see how you go :) On Wed, Jan 19, 2011 at 10:22 PM, Ryan Schmidt <[email protected]>wrote: > On Jan 19, 2011, at 04:39, Greg Skerman wrote: > > > You're not changing the way that cakephp manages the relationships.... > Book hasMany Transactions (or whatever you call it).... and User hasMany > Transactions also. > > Well, it's changing the relationships in that before, Book belongsTo User > and User hasMany Book. If I have an instance of Book, I can easily see who > the current User for that Book is, because there's only one. Now, if I have > an instance of Book, there might be several associated instances of User > that I have to wade through to find the one to whom the book is currently > checked out. > > I was also comparing it to a standard HABTM relationship, where there is a > join table, whose name is dictated/recommended (table1_table2) and where I > have thus far not been creating my own model classes; with your transactions > table, it sounds like I will be creating a model for it, and its name can be > anything I choose. > > It sounds like this may work. Thanks. Still trying to work it all out in my > head. > > > > don't put the user_id in the book table (user has books by virtue of > having transactions....) - use the transactions table to bridge between > Users and Books. You get the current user that has the book checked out by > querying the transactions table for the latest checked out date where > checkin date is null for a given book_id, and pull user_id from the > transactions table. > > I guess I'll just have to dive in and try it. > > > On Jan 19, 2011, at 04:40, Greg Skerman wrote: > > > Further, you could throw a "model" field in the transactions table, and > just have one single transactions table that manages every asset you are > trying to track - just always filter for model = "book" whenever you want to > know whats going on with books, and model = "widget" when you want to know > whats going on with widget.... > > > > Again, you can then query the transactions table to find out everything > the user has (books, widgets, gizmos, whatever) at once, out of one table, > without having to query multiple tables... > > That does sound practical and desirable, but I'm worried that this means I > can't then define foreign keys properly in the transactions table. And I was > under the impression that one should strive to set up foreign keys properly > in the database. I'm also not sure how to set up CakePHP foreign keys / > associations when the let's say object_id field in the transactions table > does not always refer to the same kind of object. > > > > > -- > Our newest site for the community: CakePHP Video Tutorials > http://tv.cakephp.org > Check out the new CakePHP Questions site http://ask.cakephp.org and help > others with their CakePHP related questions. > > > To unsubscribe from this group, send email to > [email protected]<cake-php%[email protected]>For > more options, visit this group at > http://groups.google.com/group/cake-php > -- Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions. To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/cake-php
