Hey,
Is there any way I can have a model to store an N by N integer matrix?
Something that would be able to keep record of rows and seats.
n[i][j] = 1 if the seat is empty
n[i][j] = 2 if the seat is reserved
Possibly
Auditorium has_many Rows
Row has_many Seats
Seat belongs_to Row
Row belongs_to Auditorium
Colin
2009/5/15 pb pb [email protected]
too much complex:)
is good enough to keep only row#nr and seat#nr, eg
table seats contains:
id
seat_number
row_number
is much faster to search/update
tom
Colin L. wrote:
–
Tomas Meinlschmidt, MS {MCT, MCP+I, MCSE, AER}, NetApp Filer/NetCache
- experienced RoR/PHP freelancer, available for hire
www.meinlschmidt.com www.maxwellrender.cz www.lightgems.cz
Colin L. wrote:
You might find the arrangement using relationships is actually
significantly
simpler to develop, and with a maximum of a few thousand seats
(presumably)
you are unlikely to notice any difference in lookup.The fact that you talk about rows suggests that this is a concept that
is
part of your mental image of the problem, it is often best to map your
mental image of the problem into the application, it makes it a better
representation of the real world, which may be much more important than
a
few milliseconds of database lookup.For example, do you wish to keep the number of seats in each row
somewhere?
Put it in the rows table.Colin
2009/5/15 Tom Z Meinlschmidt [email protected]
Well, each row will have the same amount of possible seats. I want to
store 1 if there’s a seat, or 0 if there’s something else, like an alley
or some obstacle.
a room plan wood look like
111111111
111110111
111110111
111110111
111110111
111110111
222222222
where the 1 signifies a seat, 0 signifies stairs and 2 is the screen.
I came up with a model
I have a class room which contains a name:string, rows:integer,
seats:integer
and then I have roomplan which has room_id:integer , row:integer,
seat:integer, value:integer to keep those 1s and 0s…
What do you think?
I would still go for Models Room, Row and Seat with the relationships as
above, it seems like a better mapping of the problem. But if your
solution
is a better mapping for the way you see the problem then that is the
best
solution for you.
Consider how to access a particular seat. In the Room, Row, Seat
solution if
you have the record for a particular room then value for seat 5 on row 3
would be referenced by
room.row[3].seat[5].value (assuming zero based indexing, you might
have to
add one to the indexes for real world mapping)
How would this be achieved with the Room and RoomPlan models?
Colin
2009/5/16 pb pb [email protected]
You might find the arrangement using relationships is actually
significantly
simpler to develop, and with a maximum of a few thousand seats
(presumably)
you are unlikely to notice any difference in lookup.
The fact that you talk about rows suggests that this is a concept that
is
part of your mental image of the problem, it is often best to map your
mental image of the problem into the application, it makes it a better
representation of the real world, which may be much more important than
a
few milliseconds of database lookup.
For example, do you wish to keep the number of seats in each row
somewhere?
Put it in the rows table.
Colin
2009/5/15 Tom Z Meinlschmidt [email protected]
Colin L. wrote:
[…]
if
you have the record for a particular room then value for seat 5 on row 3
would be referenced by
room.row[3].seat[5].value (assuming zero based indexing, you might
have to
add one to the indexes for real world mapping)
How would this be achieved with the Room and RoomPlan models?Colin
Well, another way to do it might be to simply have a 2D array serialized
to YAML. That gives the addressability without the join overhead. I
tend to agree with you, though: a separate Seat table (probably not a
Row table, though) would be good – it would allow the storage of more
than 1 byte of data for each seat…
Best,
Marnen Laibow-Koser
http://www.marnen.org
[email protected]