Bezetting hotelkamers opslaan
Ik ben hier al een hele tijd niet geweest en moet zeggen dat ik onder de indruk ben van de nieuwe website.
Ik ben bezig met een script waarmee je hotelkamers kunt reserveren. Nu vraag ik me af wat de beste manier is om de bezetting data op te slaan.
Is dit een koppel tabel, dus een tabel die communiceert met de tabel waarin de hotelkamers staan, of gewoon in één tabel, data ranges met komma gescheiden. Denk het eerste, maar misschien zie ik nog iets over het hoofd.
Alvast bedankt :) - Brian
normaliseren. Doorloop dat proces en je houd vanzelf een correct datamodel over ;-)
Edit: op basis van de informatie die je nu geeft, zou ik zoiets verwachten:
kamers
------
id
kamernummer
naam
reserveringen
-----------
id
kamer_id
aankomst_datum
vertrek_datum
De tweede oplossing is in ieder geval niet juist, dat had je goed gezien. Of de eerste wel de juiste is, hangt af van alle informatie die je in je database op wilt slaan. De enige manier om achter het juiste datamodel te komen, is door te Edit: op basis van de informatie die je nu geeft, zou ik zoiets verwachten:
kamers
------
id
kamernummer
naam
reserveringen
-----------
id
kamer_id
aankomst_datum
vertrek_datum
Gewijzigd op 31/05/2010 10:24:49 door Joren de Wit
- Brian
Zie ook de edit van mijn vorige post. Een keine opzet, die wellicht nog verandert omdat je meer informatie wilt opslaan. Bijvoorbeeld over de persoon die een kamer reserveert.
normaliseren zijn trouwens niet juist gesorteerd.
Zoiets had ik ook in gedachten maar dacht een tweede opinie kan nooit geen kwaad. :) Dank je wel. De pagina's van de tutorial Een koppeltabel wordt gebruikt om een veel-op-veel relatie te maken. Bijvoorbeeld:
gebruiker <> gebruiker_groep <> groep
Meerdere gebruikers kunnen in meerdere groepen zitten.
Offtopic:
De tutorial heeft nu in de rechterbalk geen titels om door de pagina's te navigeren.
Offtopic:
Zie dat de inhoudsopgave nu weer terug is. Vorige / volgende pagina werkte net niet maar nu wel, volgens mij is er iemand bezig...
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
hotelrooms
id int(11)
room_number int(5)
room_number_additive varchar(5)
room_name varchar(20)
photo1 varchar(40)
photo2 varchar(40)
photo3 varchar(40)
room_occupation
room_id int(11)
date_from datetime
date_till datetime
date_reservation Datetime
customer_id varchar(40)
customers
id int(11)
name varchar(20)
surname varchar(50)
address varchar(40)
postalcode varchar(6)
city varchar(30)
telephone varchar(13)
email varchar(150)
notes text
id int(11)
room_number int(5)
room_number_additive varchar(5)
room_name varchar(20)
photo1 varchar(40)
photo2 varchar(40)
photo3 varchar(40)
room_occupation
room_id int(11)
date_from datetime
date_till datetime
date_reservation Datetime
customer_id varchar(40)
customers
id int(11)
name varchar(20)
surname varchar(50)
address varchar(40)
postalcode varchar(6)
city varchar(30)
telephone varchar(13)
email varchar(150)
notes text
Voordat ik ga programmeren wil ik zeker weten dat ik niets over het hoofd zie. Vergeet ik nog iets?
Offtopic:
Welkom terug Brian :) Laatste keer dat je hier was, was in 2007 zie ik.
Gewijzigd op 31/05/2010 11:52:38 door B a s
Goed idee.. Heb ik nu aangepast :) Nu zit je ook niet aan slechts 3 foto's vast ;) Dank je wel
Ik zit te denken om een `owner_id` toe te voegen aan de bestaande tabellen die aangeeft van welk hotel die record is.
Over traagheid: een database is ervoor gemaakt om miljoenen records te bevatten. Zolang je structuur klopt en de juiste indexen gebruikt, hoeft dat dus geen probleem te zijn.
Oke super dank je wel :D
Let er op dat je dan nog een tabel hebt en dat een kamer een relatie heeft met die nieuwe tabel. En hou er ook rekening mee dat je de klanten ook via een relatie aan de nieuwe tabel linkt. Anders zouden de klanten van Hotel X door Hotel Y gevonden worden.
Je huidige tabel room_occupation moet nog een eigen id hebben. Je zou kunnen zeggen dat de primaire index van die tabel de samengestelde sleutel 'room_id' en 'customer_id' is, maar dat zou betekenen dat een klant een kamer slechts een keer kan reserveren.
Zoals die tabel nu is opgezet is het een koppeltabel, immers meerdere klanten kunnen meerdere kamers reserveren, maar dan wel slechts een keer. Je wilt hier een tabel van maken met meerdere 1-op-veel relaties, waarbij een eigen id zorgt voor de primaire index.
Elwin Fratsloos op 31/05/2010 12:08:12:
Je wilt hier een tabel van maken met meerdere 1-op-veel relaties, waarbij een eigen id zorgt voor de primaire index.
Veel-op-veel relaties toch? Meerdere gasten kunnen meerdere kamers boeken. Goed punt van het eigen id, die had ik nog niet eens gezien :-)
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
hotel
hotel_id int(11)
hotel_name int(11)
hotel_logo datetime
hotel_address datetime
hotel_address_number int(8)
hotel_address_additive varchar(8)
hotel_postal_code varchar(6)
hotel_city varchar(39)
hotel_telephone varchar(13)
hotel_email varchar(150)
hotel_website varchar(80)
hotel_description text
hotelrooms
room_id int(11)
room_number int(5)
room_number_additive varchar(5)
room_name varchar(20)
hotel_id int(11)
room_photos
photo_id int(11)
room_id int(11)
photo_name datetime
photo_postdate datetime
sort Int(2)
room_occupation
id int(11)
room_id int(11)
date_from datetime
date_till datetime
date_reservation Datetime
customer_id varchar(40)
customers
id int(11)
customer_name varchar(20)
customer_surname varchar(50)
customer_address varchar(40)
customer_address_number int(5)
customer_address_additive varchar(5)
customer_postal_code varchar(6)
customer_city varchar(30)
customer_telephone varchar(13)
customer_email varchar(150)
customer_notes text
hotel_id int(11)
hotel_id int(11)
hotel_name int(11)
hotel_logo datetime
hotel_address datetime
hotel_address_number int(8)
hotel_address_additive varchar(8)
hotel_postal_code varchar(6)
hotel_city varchar(39)
hotel_telephone varchar(13)
hotel_email varchar(150)
hotel_website varchar(80)
hotel_description text
hotelrooms
room_id int(11)
room_number int(5)
room_number_additive varchar(5)
room_name varchar(20)
hotel_id int(11)
room_photos
photo_id int(11)
room_id int(11)
photo_name datetime
photo_postdate datetime
sort Int(2)
room_occupation
id int(11)
room_id int(11)
date_from datetime
date_till datetime
date_reservation Datetime
customer_id varchar(40)
customers
id int(11)
customer_name varchar(20)
customer_surname varchar(50)
customer_address varchar(40)
customer_address_number int(5)
customer_address_additive varchar(5)
customer_postal_code varchar(6)
customer_city varchar(30)
customer_telephone varchar(13)
customer_email varchar(150)
customer_notes text
hotel_id int(11)
Gewijzigd op 31/05/2010 12:36:47 door Brian Valenburg
room_occupation.date_from datetime --> Waarom geen date?
room_occupation.date_till datetime -- Waarom geen date?
customers.hotel_id int(11) --> Deze hoort hier niet. In welk hotel een gast verblijft wordt vastgelegd via de room_occupation tabel. Op deze manier zou een gast maar in 1 van de hotels kunnen verblijven, en nooit meer in een ander...
Super, ik koppel er wel een login systeem aan dan zodat klanten zich één keer registreren en kunnen inloggen. Was eerst de bedoeling dat ze iedere keer hun naw gegevens opgeven. Die van de date is ook een goede inderdaad. Tnx voor jullie hulp nogmaals!
Brian Valenburg op 31/05/2010 12:47:04:
Super, ik koppel er wel een login systeem aan dan zodat klanten zich één keer registreren en kunnen inloggen. Was eerst de bedoeling dat ze iedere keer hun naw gegevens opgeven.
Dan lijkt het mij een stuk gebruiksvriendelijker om bij een volgende keer te vragen of de naw gegeven van de gast nog kloppen, ipv ze elke keer opnieuw in te laten vullen. ;-)
Blanche PHP op 31/05/2010 12:16:50:
Volgens mij meerdere 1-op-veel relaties, omdat de reservering uniek is. Maar met die meerdere 1-op-veel relaties kan je meerdere kamers door meerdere klanten laten reserveren en blijft de reservering uniek.Veel-op-veel relaties toch? Meerdere gasten kunnen meerdere kamers boeken. Goed punt van het eigen id, die had ik nog niet eens gezien :-)
Blanche PHP op 31/05/2010 12:41:06:
Dat is een keuze die gemaakt moet worden. Allebei is in principe goed. Nu kan je zeggen dat de medewerkers van Hotel X de klanten van Hotel Y in kunnen kijken. Dat is ook weer niet goed.customers.hotel_id int(11) --> Deze hoort hier niet. In welk hotel een gast verblijft wordt vastgelegd via de room_occupation tabel. Op deze manier zou een gast maar in 1 van de hotels kunnen verblijven, en nooit meer in een ander...
De keus moet m.i. gemaakt worden na het beslissen van het volgende:
- is het een eigen systeem, op een eigen site, waar de klanten kunnen inloggen? Dus de site fungeert dan als tussenpersoon voor de hotels. Dan moet de hotel_id niet bij de klant opgeslagen worden, dan wordt het zeg maar een account waarmee je bij meerdere hotels kan reserveren.
- is het een te integreren systeem, oid? Dan moet je het hotel_id wel bij de klant opslaan, omdat de hotels dan niets met elkaar te maken hebben. Het zou dan raar zijn als je vraagt: 'bent u al geregistreerd bij Hotel X, of Hotel Y of Hotel Z?'. Puur alleen omdat je dan de klantgegevens hergebruikt.
Edit:
Let op voor overnormalisatie! Zie de laatste reacties van de tutorial. Je zou eigenlijk per reservering die adresgegevens op moeten slaan. En op basis van bovenstaande reacties (die tijdens deze reactie waren gepost) zou je de hotel_id niet bij de klant op moeten slaan.
Gewijzigd op 31/05/2010 12:55:11 door Elwin - Fratsloos