Owain wrote: > On Aug 25, 6:16�pm, Marnen Laibow-Koser <[email protected]> wrote: >> >> object in your DB, I think. That will give you the queries you mention >> >> > pencil_booker, green >> > 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.
Then it at least needs to store a resource count. Perhaps that's *all* it needs to store, not a separate record for each resource or an array of resource IDs? > >> >> > 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. It can, with some further tricks. Can you get into more detail about your use case? It seems like every time I try to simplify your data model, we discover a new wrinkle... > >> >> >> > 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. The two are interdependent. > 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. If it is a "thing", it needs a record IMHO. [...] > I'll put some more effort into the de-normalised approach and see > where I get to. It is the wrong approach. It will be harder to query and will not scale. Don't waste any more time on it. > > O. > > 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.
