On Aug 25, 6:16 pm, Marnen Laibow-Koser <[email protected]> wrote: > 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.
It does need to track booked resources for the yield management functionality of the booking engine. i.e. it does dynamic price calculation based on availability. > > > 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. > That doesn't cleanly work for non-contiguous periods, which I need. > > > > A sledgehammer to crack a nut? > > No, just poor data modeling. > I think we can easily fall into the trap of confusing data modelling with foisting a data model onto a database implementation. There is a logical model and there is the normalised technical model. I am really at the logical model stage where a resource is just a "thing" and that's all I need to track in the booking engine. It has no other attributes. It looks like MongoDB has support for arrays and therefore sets where you can query against arrays. See http://railstips.org/blog/archives/2009/12/18/why-i-think-mongo-is-to-databases-what-rails-was-to-frameworks/ Picking the right tool for the logical design is not always possible but at this stage I am lucky enough to have a blank(ish) sheet of paper. I'll put some more effort into the de-normalised approach and see where I get to. O. O. -- 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.
