StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>(<strong>Edit</strong> Changed my suggestion after thinking about this more. It's a deeper puzzle than I first thought.)</p> <p>My preference would be to have the Reservation having a many-to-many relationship (using a bridge table) with rooms. Call this table, with ReservationID and RoomID foreign keys, something like . . . <em>Booking</em>. Maybe you can think of a better name. A Booking is a particular room being reserved. Then, I'd have another bridge table representing the relationship between a Guest and a Booking. You could maybe call that a <em>Lodging</em>. A Lodging is a particular guest being assigned to a particular Booking (a booked room).</p> <p>This is a neat puzzle you have. The key is that you have several concrete things that exist on their own and are obviously necessary (reservation, room, guest), but also several other concepts, each with their own attributes, and spring from the relationship between these things. If this is going to be normalized correctly, you might end up with more tables than you guessed. Don't think of this as getting more complicated. Having the <strong>enough of the proper tables is what's going to ultimately simplify this</strong>. Here are some other suggestions:</p> <ul> <li>Spend time on the names of each table. My suggestions above are pretty good, but you can probably improve them. A booking is both a relationship between other things, but becomes a think itself, with at least one foreign key on another table.</li> <li>You should be able to describe what a record on a table represents. If you can't do that, then your tables suck. See above how I can describe what a booking and lodging are. Your design might end up being different, but as you brainstorm different tables, make sure you can describe what a record on that table actually is.</li> <li>Consider having Guest and Client being from the same table. They're both "Contacts" really. Someone might be a Guest at one point, but a Client the next month. You might ave an extra data table (one to 0-or-1) for when a Contact is the <em>Client</em>. You're system would only demand basic Contact information if someone is going to just act as a Guest, but more if they're acting as a Client. </li> </ul>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload