I will assume that your requirement specify the following with regards to books and users of a library. Book may be realized by one or more Copy User may be borrower of one or more Copy Copy may be borrowed by none or one User User may be requester of one or more Reservation Book may be reserved by one or more Reservation
Where: Book contains information on the author, the summary, ISBN, publication dates etc. Copy contains information on the specific copy of the book (shelf location, etc.). User contains information on the user of the library. Reservation contains information on the reservations made by a user for a book (date, etc.). The above describes in short, the operational aspect of the applications database. That is to provide books for borrowing by users. I added the possibility for users to reserve a book. In order to provide you with additional information on when, what and who, the historical aspect should be registered too. I would consider using another database for this, thus not messing up the operational database with historical information. If your application is for "playing around" you could go for additional tables in the same database as the operational database. Does the above match your requirement? Enjoy, John On 16 Jan., 13:20, Ryan Schmidt <[email protected]> wrote: > The subject of this message isn't quite right but maybe it gets the idea > across. > > Consider a system modeling a library. There are users who can check out > books. Logically we want to be able to create an association between a user > and a book when they check that book out. And of course a book that's already > checked out to a user cannot be checked out to a different user until it's > returned. Naively, when a user returns a book, we might delete the > association. But imagine I want to be able to answer questions like which > users have ever checked out this book and when? Which books has this user > ever checked out and when? What books did this user have checked out during > May? And so on. Clearly, to answer these questions, association needs to > remain in some form after one might otherwise have deleted it. How is this > type of situation typically modeled in CakePHP? Is there sample code or a > section in the book I should refer to for this? > > I imagine there would be a separate table (and model?) for checking out a > book. It would have an autoincrement id, the book id, the user id, the > checkout date, and the return date. What I'm not sure about is how much of > that Cake will manage for me and how much I need to manage myself; whether > such a table would replace, or be in addition to, a regular hasMany > relationship, etc. > > Thanks for your help. Check out the new CakePHP Questions site http://cakeqs.org and help others with their CakePHP related questions. You received this message because you are subscribed to the Google Groups "CakePHP" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/cake-php?hl=en
