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.
Ik heb nog één vraag. Ik wil een cumulatief systeem maken voor meerdere hotels. Is het verstandig om dit in één grote database te doen of vertraagd dit de boel?
Ik zit te denken om een `owner_id` toe te voegen aan de bestaande tabellen die aangeeft van welk hotel die record is.
Je kunt prima nog een tabel met hotels toevoegen. De enige tabel die je vervolgens hoeft te wijzigen, is de hotelrooms tabel. Deze krijgt dan immers een kolom hotel_id erbij om aan te geven in welk hotel de kamer zich bevindt.
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.
Dat zou je in een grote DB kunnen doen. Moet geen probleem zijn als je je queries goed op orde hebt.
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.
room_photos.photo_name datetime? --> Lijkt me varchar
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!
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. ;-)
Veel-op-veel relaties toch? Meerdere gasten kunnen meerdere kamers boeken. Goed punt van het eigen id, die had ik nog niet eens gezien :-)
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.
Blanche PHP op 31/05/2010 12:41:06
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...
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.
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.
