Owain wrote: > Marnen > > Thank you for taking the trouble to reply. > > On Aug 25, 5:40�pm, Marnen Laibow-Koser <[email protected]> wrote: >> Owain wrote: > >> >> No, I think it does. �You *want* each resource to be a separate object >> in your application, and you *want* each resource to be a separate >> object in your DB, I think. �That will give you the queries you mention >> above, and keep each resource individually addressable. >> >> Why do you think you don't need to do this? �It seems like the best way >> to me. > > The thing is that there is no other attribute of the model needed by > the booking engine other than 'id'. So imagine that the resources > being booked were coloured pencils. A booking would be for red, blue > and green. There is no need to have another table for colours. The > availability object would hold all of the available colours.
...but wouldn't tell you anything about the unavailable colors, and wouldn't easily let you query the availability of an individual color. > I don't > really see the point of the having a table with the following rows: > > application_id, resource > pencil_booker, red > pencil_booker, orange > pencil_booker, yellow > pencil_booker, green > pencil_booker, blue > pencil_booker, indigo > pencil_booker, violet > pencil_booker, dayglow_yellow The point is that each resource really is a different entity in your application's terms, so it should be treated like one. > > And maybe this is the difference, this table DOES exist in another > form in the RoR application that calls the webservice. So the calling > service knows that orange has an id of 1234567 and the booking engine > sees that as a resource available and for booking. The booking > service is not domain specific, it just implements some booking > logic. Then perhaps the booking service shouldn't store resources at all, but should just call the actual agency (say, the pencil box) responsible for reservations and return a response code. > Taking a real example, using our traditional approach I would need to > set up a the resource table with a row for every day that is made > available (using its Julian form as an id) with a HABTM relationship > through an associative entity table just to be able to be able to find > all bookings for a particular day or week? No. You probably wouldn't want to consider a day to be a resource. Rather, each booking should have a start time and and an end time. > > A sledgehammer to crack a nut? No, just poor data modeling. > > O. Best, -- Marnen Laibow-Koser http://www.marnen.org [email protected] -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" 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/rubyonrails-talk?hl=en.
