Forum: Ruby on Rails Booking system

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Rodrigo A. (Guest)
on 2006-02-17 12:05
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!
Alain R. (Guest)
on 2006-02-17 14:18
(Received via mailing list)
Rodrigo


What about using tags?

Alain
Chris M. (Guest)
on 2006-02-20 10:53
(Received via mailing list)
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
This topic is locked and can not be replied to.