Suddenly totally confused: does booking mean changing the date?

[Sigrid Kajdan]

Hi all,

I'm just re-reading the instructions.html - should have been the last step before finishing, hopefully, this evening, after nearly 2 years - and now I'm caught by one thing I didn't think about at all:

I always assumed that you have one record per hotel room, so when you book a room you modify date and owner. Otherwise, you'd have to create a new record per hotel room, per night...!

Unfortunately, I always took this completely for granted, so I didn't even think about the pro's and con's. Now, thinking about it - what is totally illogical about my way is that you can only book the next night when the one previously booked has passed... !

On the other hand, if there's a record per night - who is creating all those records?

Or should it work like this: The user edits the date and puts a new one, and I CREATE a new entry in the database at that moment? I never thought of that, because I always equated booking (in the client) with updating (in the db access part).

I'm really totally confused now, especially as I wanted to submit right now... I also wonder why I didn't even think about it. Perhaps because
this "database" is so unrealistic anyway - if you had had one table describing the rooms, and one mapping a date and a customer ID to the room id...

I'd be glad for any help here...

Ciao
Sigrid

I'm really totally confused now

[Roberto Perillo]

Howdy, Sigrid!

Champion, the only thing you have to do is modify the owner ID field of the record being booked. Practically, you should only use the update() method of your Data class to do so. You are not required to create new records. Instead, you should only use the records that exist in the .db file that is provided to you when the application starts, and who creates them doesn't really matter. The thing is, let's say that the owner ID field of record 1 is empty, and a client wants to book this room. Your application has to provide a way for the user to provide a customer ID (you may verify this, but in the instructions I received, it says that it is an 8 digit number known by the CSRs, so you may assume that any 8 digit number is valid) and update the record properly. That's just it! You are not required to provide a way to create or delete records.

[Roel De Nijs]

Hi Sigrid,

I don't know what you are talking about. The booking of a room is very simple:

CSR selects a record

CSR clicks Book-button

CSR enters an 8 digit number

CSR confirms booking (and then the record in the database file is updated accordingly)

As you can see from this little scenario the date is completely unchanged (even not mentioned at all), and I don't create extra records or delete them.

Kind regards,
Roel

[Sigrid Kajdan]

Hi Bob, hi Roel,

thanks a lot for your quick and very helpful replies!

I think I will modify the application accordingly. As you two have passed (and with what score!) your way must be correct :-)

The way I did it is really problematic for sure, because then you cannot even book a room for tomorrow night if it's reserved for this night right now, as there's only one entry per room...

On the other hand, I still wonder about the creation of new entries. I imagine there should be some batch job running in the night, creating new entries (till 48 hours in the future)...
The problem is that if I imagine starting "afresh", perhaps building an own web site for something like this, and I have a something that can be booked per date and per customer, I surely would create new entries when the booking happens - not new entries in the table for the something, but in the roomID-customerID-date lookup table....

So I fear that although the way you did it does not have the flaw that mine has, it is also not really realistic... or don't you think?

Thanks again very much
Sigrid

[Roberto Perillo]

Champion, the only thing you have to worry about is to update the customer ID field when booking a room. Indeed, you have to provide valid implementations for both the create and delete methods, but you don't have to provide this functionality. For instance, you don't have to offer this functionality in your GUI or in your business layer. There's no need to wonder what could be possibly going on in their environment. The best tip is, keep things as simple as possible.

And about the 48-hour rule, I didn't implement it. This could be controlled by the CSRs themselves.

[Sigrid Kajdan]

Hi,

I finally got it! I don't have to think about where the records come from because.. I get them from the hotels (in whatever way)!!!

So it's clear finally, I don't touch the dates :-)

Thanks again
Sigrid

[Roel De Nijs]

Sigrid Kajdan wrote:I don't touch the dates :-)

That's the spirit

Regarding the 48 hours rule: just like Roberto I didn't implement it, but I explained in choices.txt why I ignored that business rule.

Kind regards,
Roel