Stuck building Hotel database ! (1 Viewer)
- Thread starter coda7777
- Start date
It’s not about bookings at all, nothing comes concern the booking or reservation
It’s about loading and formatting the hotel contract for tour operator and in this case it’s about loading multiple hotels and all it’s data and formatting the rates of all hotels , rooms , seasons , offers into a database so we can proceed to next step which is calculations in case of bookings
How about...
I think that would work, I’ll copy that now and try it
- Local time
- Today, 01:00
- Joined
- Feb 19, 2002
- Messages
- 43,196
I'm looking at the relationship diagram and I'm trying to figure out how a single hotel can be in multiple countries?? Continuing that thought, that would put the same address, city, state, zip in multiple countries. This doesn't make sense. Therefore, get rid of tblHotelCountries and put CountryID in tblHotels.
A customer doesn't go to a country, he goes to a hotel so that relationship is not correct either.
Personally, I don't like prefixing column names with characters from the table name. You can make this work in small applications but it really falls apart in larger ones. Also, very few names are duplicated in more than one table. The address fields are frequently duplicated because not every application makes an address table which would eliminate this duplication. The prefixes just increase the number of characters you have to type before intellisense kicks in. Plus, in DS view, they make it harder to see the significant portion of the column name and finally, when you are working with a recordset, the column names are qualified by the recordset name. if you make a query that joins two tables with identical names, that is when I disambiguate them if I need to.
A customer doesn't go to a country, he goes to a hotel so that relationship is not correct either.
Personally, I don't like prefixing column names with characters from the table name. You can make this work in small applications but it really falls apart in larger ones. Also, very few names are duplicated in more than one table. The address fields are frequently duplicated because not every application makes an address table which would eliminate this duplication. The prefixes just increase the number of characters you have to type before intellisense kicks in. Plus, in DS view, they make it harder to see the significant portion of the column name and finally, when you are working with a recordset, the column names are qualified by the recordset name. if you make a query that joins two tables with identical names, that is when I disambiguate them if I need to.
GinaWhipp
AWF VIP
- Local time
- Today, 01:00
- Joined
- Jun 21, 2011
- Messages
- 5,900
From what I understood... A Customer on a Tour could be going to several Countries or multiple locations within the same Country thereby staying at multiple Hotels.
As for my Naming Convention... to each their own.
Don't really want to add on to this thread with that discussion.
As for my Naming Convention... to each their own.
Don't really want to add on to this thread with that discussion.- Local time
- Today, 01:00
- Joined
- Feb 19, 2002
- Messages
- 43,196
Sorry Gina, I didn't notice that you posted the database. I thought it was coda.
Since the database is managing reservations, the country a person is travelling to is not how the connection is made. What if there are multiple hotels in a country? By connecting person to country, you have no idea which hotel he is going to. I can understand how the form that makes the reservations might use multiple combos to drill down to a hotel but I don't see how the relationship as presented will actually work. How can you tell WHICH hotel a person is registered in? I must be missing something.
As to the prefixes. I didn't mean to imply that they are wrong, in fact 45 years ago when I was doing mainframe work, I always prefixed all my column names but intellisense got me out of that habit. If you are using a platform that supports intellisense, I think suffixes make more sense if you want unique column names across the whole schema. The point is to type as few characters as possible to get to the name you want.
Since the database is managing reservations, the country a person is travelling to is not how the connection is made. What if there are multiple hotels in a country? By connecting person to country, you have no idea which hotel he is going to. I can understand how the form that makes the reservations might use multiple combos to drill down to a hotel but I don't see how the relationship as presented will actually work. How can you tell WHICH hotel a person is registered in? I must be missing something.
As to the prefixes. I didn't mean to imply that they are wrong, in fact 45 years ago when I was doing mainframe work, I always prefixed all my column names but intellisense got me out of that habit. If you are using a platform that supports intellisense, I think suffixes make more sense if you want unique column names across the whole schema. The point is to type as few characters as possible to get to the name you want.
GinaWhipp
AWF VIP
- Local time
- Today, 01:00
- Joined
- Jun 21, 2011
- Messages
- 5,900
No problem.
I got the impression it was handling tours and the reservations during such tour. So I did the Customer > Destination(s) > Hotel(s). Side note, I originally posted a Hotel Reservation Data Model and then it was explained that the Reservations were not the primary.
As to the prefixes, I too have been doing for more years then I care to mention and 99.9$ of my Functions and code already take them into account. So, if I changed now, not that I would to as I like them, I would have have tons of re-usable code and Functions to update. Well, maybe not Functions as only about .5 % take actual table and\or field names into account.
I got the impression it was handling tours and the reservations during such tour. So I did the Customer > Destination(s) > Hotel(s). Side note, I originally posted a Hotel Reservation Data Model and then it was explained that the Reservations were not the primary.
As to the prefixes, I too have been doing for more years then I care to mention and 99.9$ of my Functions and code already take them into account. So, if I changed now, not that I would to as I like them, I would have have tons of re-usable code and Functions to update. Well, maybe not Functions as only about .5 % take actual table and\or field names into account.
