Owain wrote: > I am at the very early design stages of a web service to implement a > "booking engine". I want it to be a generic in so far as the resource > being booked could be anything, a tennis court, hotel room, ski chalet > or airline seat. It's up to the client (RoR) application calling the > webservice to determine what the resource is, who can book it etc etc. > > so really all I need is "booking" and "availability" where > availability is a set of resources, and a booking is a subset (not > necessarily contiguous) of resources. But the point is that a > resource is just a unique numeric key, it has no other attribute. So > it would be terrific to implement the webservice schema using set > theory in Ruby. > > require 'set' > require 'yaml' > availability = Set.new [1,2,3,4,5,6,7,8,9,10,11,12,14] > booking = Set.new(4..8).to_a > > and then be able to use the standard set operators to check there is > availability (is a subset) and all of the others. > > So what I need is to store a set of integers as a set within the > database (in a column?) to represent a set of resources.
No, you probably don't. > That could > be done by serializing the Set object but then I lose the ability of > database queries (in particular indexing performance gains) to do > something like, show me all of the bookings of the resources [11, 14, > 16], which is of course another set. > > But a relational database is just set theory in disguise I hear you > say! But surely my webservice does not need to have a table called > Resource with a column called application_id and a column called > resource_id (and the extra id created by Active Record). 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. > > My gut feel is that I am approaching this in the wrong way. You absolutely are. You should be using the relational model for what it's good at, not trying to defeat it. > Perhaps > Active Record is the wrong approach. ActiveRecord is the right approach. Serialized arrays are the wrong approac. > I have had a look at Nested Sets > but that isn't the functionality I am after. Or am I? No. Those are for tree structures. > > Does anyone have any suggestions as to a sensible design approach? Yes! Keep each resource as a separate record. > > 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.
