Hi! I'm planning a booking system in rails, and I have the following issue: There will be room_types. I can implement this with STI in the rooms table, or with a separate table room_types. Each room type will have its special features. For example: Room::SingleRoom # For 1 person Room::DoubleRoom # Simply for 2 people Room::DoubleRoom::SingleDoubleRoom # If only for 1 person will be cheaper Room::DoubleRoom::ExtraBedDoubleRoom # 3 people can use it (more expensive) Room::Apartment # For example, between 4-6 people, with different prices each etc... There is another approach, with a room_types table. It can take care of the capacities of the different rooms, allowing the customers to search. The table structure can be something like: name: the RoomType name default_capacity: The mainly used capacity (2 In case of ExtraBedDoubleRoom) maximum_capacity: The room allows more people (3 In case of ExtraBedDoubleRoom) minimum_capacity: If the customer uses this type of room but with a value lesser than this, will pay the price assigned to this minimum (2 In case of ExtraBedDoubleRoom) Remember that the system must be searchable, so the typical STI solution doesn't fit well, since I must then specify the capacities in the code! Some kind of hybrid makes more sense to me. Is there any other approach? How do you would do it? Thanks!
on 2006-02-17 11:05
on 2006-02-17 13:18
Rodrigo What about using tags? Alain
on 2006-02-20 09:53
On 17 Feb 2006, at 10:05 am, Rodrigo Alvarez wrote: > Some kind of hybrid makes more sense to me. Is there any other > approach? > How do you would do it? I'd go with your room_types idea: > name: the RoomType name > default_capacity: The mainly used capacity (2 In case of > ExtraBedDoubleRoom) > maximum_capacity: The room allows more people (3 In case of > ExtraBedDoubleRoom) > minimum_capacity: If the customer uses this type of room but with a > value lesser than this, will pay the price assigned to this minimum (2 > In case of ExtraBedDoubleRoom) There's no reason that these different room types have to be different classes in your Ruby code. As you point out, you would end up hard-coding the room types and capacities into the application. If they ever want to change the room types, or add/delete one (and you know they will!), you'll have to change the code. Using a room_types table makes this kind of thing easy. The other way to think about is this: you only need to use STI if the different classes are going to behave in different ways. The classic example is 'Employee < Person' and 'Manager < Person'. These things are both obviously people, so they'll have some common things like full_name(). But in the day-to-day activities of your application, they'll be *doing* fundamentally different things (your Managers might manage() some projects, while your Employees might carry_out() some Tasks and be managed_by(pointy_haired_boss).) That's why you want different Ruby classes for them. With Rooms, on the other hand, each of your different 'types' of room (double rooms, single rooms, double rooms with an extra bed, etc.) will have a few *properties* that are different (i.e. max_capacity of 1 or 2 or 3), but they will all *behave* in basically the same way. They'll have_many bookings placed against them, they'll be available? (tomorrow), etc. There's no benefit to having different classes for the different types of room. Chris