Booking system

Rails
1

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!

2

Rodrigo

What about using tags?

Alain

3

On 17 Feb 2006, at 10:05 am, Rodrigo A. 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