[php/mysql] opzet boekingssysteem

Pagina: 1
Acties:

Onderwerpen


Acties:
  • 0 Henk 'm!

  • BKJ
  • Registratie: April 2000
  • Laatst online: 18-09 14:52
Ik ben bezig met een online boekingsysteem in elkaar te bouwen.Het gaat om boekingen van hotelkamers bij verschillende (2) hotels.

De hotels loggen zelf in en geven per dag aan wat de prijs van een bepaalde soort kamer is en hoeveel er nog beschikbaar zijn die dag.

Vraag is nu alleen: Hoe kan je dit DB technisch realiseren? Ik zat te denken aan een tabel met voor iedere dag een entry en dat een jaar vooruit (dus 365x2x(aantal kamersoorten) rijen). Met daarbij dus een kolom voor datum, een prijs, kamersoort en aantal beschikbaar.

Stel dat het systeem meer hotels gaat bedienen. Dan gaat de tablegrootte exponentieel omhoog. Kortom: is dit een slimme aanpak? Hebben er tweakers ervaring met dit fenomeen? Hoe zou je dit ook kunnen aanpakken?

Kamer huren


Acties:
  • 0 Henk 'm!

  • Brakkie
  • Registratie: Maart 2001
  • Niet online

Brakkie

blaat

Vraag is nu alleen: Hoe kan je dit DB technisch realiseren? Ik zat te denken aan een tabel met voor iedere dag een entry en dat een jaar vooruit (dus 365x2x(aantal kamersoorten) rijen). Met daarbij dus een kolom voor datum, een prijs, kamersoort en aantal beschikbaar.
Dat lijkt me niet echt een oplossing die op de toekomst voorbereid is. Ik zou meer denken aan de volgende tabellen.

- Boekingen (boeking_id, hotel_id, kamersoort_id,klant_id, periode_start, periode_eind)
- Hotel (hotel_id, hotel_naam)
- Kamersoorten (soort_id, hotel_id, prijs_per_nacht, aantal)
- klanten (klant_id, naam)

Zal vast nog veel beter kunnen maar het lijkt me in ieder geval al iets flexibeler dan wat jij hebt. Zoek ook eens op database normalisatie op google.

[ Voor 15% gewijzigd door Brakkie op 12-08-2005 13:36 ]

Systeem | Strava


Acties:
  • 0 Henk 'm!

  • djluc
  • Registratie: Oktober 2002
  • Laatst online: 14:28
tabel hotels
(ID/naam)
tabel kamers
(hotel ID/aantal bedden/prijs)
tabel beschikbaarheid
(kamerID/ ja-nee veld/ datum)

Acties:
  • 0 Henk 'm!

  • supersook
  • Registratie: Januari 2001
  • Laatst online: 28-07 17:09

supersook

Professioneel prutser

Ik ben niet een database guru ofzo, maar wat mij betreft is je opzet/idee van de database fundementeel fout (no offence hoor).

Volgens mij denk jij bij een database nog steeds aan een excel sheet die je van tevoren moet opmaken en indelen en sorteren om er snel informatie uit te halen. Een database is echt anders qua opzet. Je werkt nog steeds met rijen (records) en kolommen (fields) welke je op alle mogelijke manieren kunt sorteren, filteren en combineren. Een database is alleen niet te grijpen in een enkel uiterlijk, laat staan dat voor elke mogelijke combinatie van informatie al een rij wordt gereserveerd. Je kunt het beter zien als een informatiebuttler waar je, naar gelang je database opzet, best ingewikkelde vragen aan kunt stellen. Lees voor de aardigheid dit eens door: http://www.geekgirls.com/databasics_01.htm.

Voor het idee van de hotel-database hoef je dus niet voor elke mogelijke dag/kamer al een record aan te maken, je hoeft immers alleen informatie op te slaan over al gereserveerde kamers.

Lees na het vorige artikel ook het volgende eens: http://www.phpfreakz.nl/artikelen.php?aid=19

[ Voor 22% gewijzigd door supersook op 12-08-2005 13:18 ]


Acties:
  • 0 Henk 'm!

  • supakeen
  • Registratie: December 2000
  • Laatst online: 09-09 14:42
table hotels
id,
created,
changed,
hotelnaam,
(en wat je nog meer bij hotels wil)

table kamers
id,
created,
changed,
kamer_prijs,
aantal_bedden,
bezet_of_niet

table relations
id,
relation_type,
master_id,
slave_id

Zoiets voor even snel simpel niet uitgedacht? Via de relations gooi je dus alles aan elkaar vast. Via een systeem geven de hotels op per kamer (vinkjes of iets dergelijks) of de kamer vrij is of bezet voor die dag. En de rest mag je zelf uitzoeken :>

[ Voor 33% gewijzigd door supakeen op 12-08-2005 13:32 ]


Acties:
  • 0 Henk 'm!

  • BKJ
  • Registratie: April 2000
  • Laatst online: 18-09 14:52
supersook schreef op vrijdag 12 augustus 2005 @ 13:13:


Voor het idee van de hotel-database hoef je dus niet voor elke mogelijke dag/kamer al een record aan te maken, je hoeft immers alleen informatie op te slaan over al gereserveerde kamers.

[/url]
Het systeem is niet het enige systeem wat de kamers boekt. De informatie in de DB is dus niet de enige bron. Hotels geven aan hoeveel ze die dag beschikbaar hebben via dit kanaal. Zo moet je dus ook in de toekomst al het hele hotel kunnen blokken (alles dichtzetten) omdat je niet wil dat dit kanaal kamers bij je boekt.

Hoe kan je dit dan integreren?

Kamer huren


Acties:
  • 0 Henk 'm!

  • supakeen
  • Registratie: December 2000
  • Laatst online: 09-09 14:42
hitchhacker schreef op vrijdag 12 augustus 2005 @ 13:59:
[...]


Het systeem is niet het enige systeem wat de kamers boekt. De informatie in de DB is dus niet de enige bron. Hotels geven aan hoeveel ze die dag beschikbaar hebben via dit kanaal. Zo moet je dus ook in de toekomst al het hele hotel kunnen blokken (alles dichtzetten) omdat je niet wil dat dit kanaal kamers bij je boekt.

Hoe kan je dit dan integreren?
Veldje bij het hotel met een 0 of 1 erin of het mag boeken of niet?

Acties:
  • 0 Henk 'm!

  • Brakkie
  • Registratie: Maart 2001
  • Niet online

Brakkie

blaat

Je hebt een complexe opdracht als dit gekregen maar je hebt zelf geen enkel benul hoe je dit moet oplossen? Lekker voor je opdrachtgever.

Systeem | Strava


Acties:
  • 0 Henk 'm!

  • BKJ
  • Registratie: April 2000
  • Laatst online: 18-09 14:52
Brakkie schreef op vrijdag 12 augustus 2005 @ 14:48:
Je hebt een complexe opdracht als dit gekregen maar je hebt zelf geen enkel benul hoe je dit moet oplossen? Lekker voor je opdrachtgever.
(op zich nutteloze reply, maar ik zal even antwoorden)

Ik kan het theoretisch oplossen maar het blijkt erg inefficient te zijn. Vandaar mijn vraag voor verbetering. En tot aan jou reply had ik ook daadwerkelijk kwalitatief goede adviezen.

Kamer huren


Acties:
  • 0 Henk 'm!

  • Brakkie
  • Registratie: Maart 2001
  • Niet online

Brakkie

blaat

hitchhacker schreef op vrijdag 12 augustus 2005 @ 16:47:
[...]


(op zich nutteloze reply, maar ik zal even antwoorden)

Ik kan het theoretisch oplossen maar het blijkt erg inefficient te zijn. Vandaar mijn vraag voor verbetering. En tot aan jou reply had ik ook daadwerkelijk kwalitatief goede adviezen.
Ik vond dat ik deze reply wel mocht maken aangezien ik ook al nuttig bedoelde input gegeven had.

Ik vond m'n reply helemaal niet zo nutteloos omdat je in eerste instantie met een redelijk summiere beschrijving van het te bouwen product en wat je zelf al hebt bedacht/gebouwd komt. Daarna vraag je ook nog even tussen neus en lippen door hoe je bepaalde systemen weer kan koppelen.

Misschien had ik het wat subtieler kunnen verwoorden. Maar een iets uitgebreidere beschrijving van het systeem en wat je zelf al bedacht hebt zou handig zijn.

Systeem | Strava


Acties:
  • 0 Henk 'm!

  • ripexx
  • Registratie: Juli 2002
  • Laatst online: 17-09 20:52

ripexx

bibs

Om je even op weg te helpen zelf met een goed oplossing te komen.

Het opzetten van een basis database model gaat volgens het principe van normaliseren. Deze regels zijn redelijk eenvoudig, er zijn zat topic over te vinden en ook google zal je op weg helpen.

Het probleem van een boekingsysteem zit vaak niet in de registratie maar in het zoeken naar een vrije periode. De basis gaat dus uit van kamers, mensen die boeken en de werkelijk boeking. Eventueel kan je dat nog verder uitwerken naar verschillende hotel zoals Brakkie en znm al aangeven.

Een goede manier om te beginnen is gewoon eens op te schrijven welke gegevens je allemaal nodig hebt. Daarna kanje bijvoorbeeld in Access of Viso gaan beginnen met het ontwerpen of teken op papier het een en ander uit.

Je huidige opzet is dus niet de way to go maar dat was je waarschijnlijk al duidelijk ;)

buit is binnen sukkel

Pagina: 1