[php,sql] Ontwerp van een reserverings/plannings systeem

[Infern0]

Ik heb een mooi opdracht gekregen om als bijbaantje te doen. Het betreft een plannings en reserverings systeem voor kamers voor buitenlandse studenten.

Ik heb al een redelijk uitgewerkt ontwerp, echter wilde ik jullie mening even hebben over mijn opzet, omdat ik nog nooit zo'n groot iets heb gemaakt voor iemand anders. Want dit is wel iets anders als een website voor jezelf.

----------
Opzet:
We hebben een clienten DB met daarin de standaard data (naam,adres enz) en belangrijkste hierin is: "gewenste datum van een kamer" en "kamer nodig tot".

Daarnaast hebben we een accomodatie DB met daarin de data voor een accomodatie (een kamer zeg maar). In deze DB zit een bool "beschikbaar" verder niet zoveel bijzonders.

Dit is allemaal nog redelijk standaard.
Nu moeten we dus een client gaan koppelen aan een accomodatie, daarvoor moet er een aanbieding gedaan worden aan de client.

Dit doen we door een selectie te maken uit de clienten DB (bv op "datum kamer nodig" en prioriteit). Deze lijst zetten we links op het scherm.

Daarna gaan we een selectie maken uit de accomodaties welke beschikbaar zijn (adhv reservering db zie verderop).
Deze selectie komt rechts op scherm. Nu moet er door de gebruiker een match gemaakt worden. Dus client_id=4 en accomodatie_id=3 selecteren en op "GO" drukken.

Deze aanbieding wordt in de aanbiedings db gezet met daarin:
#aanbieding_id ; client_id ; accomodatie_id ; datum_aanbieding
hierna wordt de accomodatie op niet beschikbaar gezet (er kunnen geen 2 aanbiedingen voor 1 kamer gedaan worden)

Als de client accoord gaat met de aanbieding wordt de aanbieding verplaatst naar de reserverings db met daarin:
#reservering_id ; client_id ; accomodatie_id ; datum_in ; datum_uit
en tevens wordt de accomodatie weer beschikbaar gemaakt (zodat deze voor een volgende periode wel weer zichtbaar is in de selectie)

Gaat de client niet accoord, dan wordt de aanbieding verwijderd en gaat de kamer afwijzing_teller van de client omhoog en wordt de afwijzing in een andere DB gezet. Dit is handig, want dan kan gekeken worden of er een trend zit in het afwijzen van bv type kamers.


Mijn idee was om de reserverings en afwijzings DB per jaar te maken, zodat je wat eenvoudigere overzichten krijgt. Of is dit niet handig omdat je bv overlappende tijden hebt (een student kan een kamer huren van 1-12-2003 t/m 1-2-2004)??
-------
Dit zeg maar het globale verhaal, het gaat er mij vooral om of mijn werkwijze een beetje logisch is.
Handige tips voor het opzetten van zoiets zijn ook zeer welkom.

Dit geheel komt te draaien op een FreeBSD servertje PII 400 ofzo. Er werken maximaal 2 mensen tegelijkertijd met deze DB. Dit systeem is ook alleen toeganlijk voor een kleine groep mensen (4 a 5). Dus security is niet super belangrijk.

Ik ga ook gebruik maken van PostgreSQL, omdat deze foreign keys ondersteund en me dit wel erg handig leek in deze opzet. En de mogelijkheid van sub-query's (of zeg ik het nu verkeerd?? ik bedoel dus SELECT * FROM bla WHERE a=(SELECT.... )

Dus mensen spui je mening, graag opbouwende kritiek.

[Pelle]

De manier van kamers weggeven lijkt me een beetje de omgekeerde wereld. Ik zou een groot overzicht laten zien, van kamers die beschikbaar zijn. Na het aanklikken van een kamer, zoek je er de meest geschikte persoon voor.. aan de hand van registratiedatum, prioriteit of whatever.
Gezien het feit dat er waarschijnlijk meer studenten dan kamers zijn, is het makkelijker om een kamer aan de meest geschikte student toe te wijzen dan om een student te pakken en daar een kamer voor te vinden. Mocht je hier voor kiezen, zorg dan wel voor eenduidige selectiecriteria, anders loop je alsnog de mist in. Je systeem werkt dan wel, maar dan zullen er studenten zijn waarvoor nooit een kamer voor zal worden gevonden en dat wil je voorkomen.

Verder lijkt het me erg slim om even naar je datamodel te kijken. Een aparte aanbiedingen / reserveringentabel lijkt me overbodig, deze zijn best samen te voegen en te onderscheiden middels een boolean veldje (reservering definitief ja / nee). Is er een goede match tussen kamer & kamerzoekende, dan koppel je die twee aan elkaar. Gaat de deal door, hoog je die boolean even op en is er sprake van een reservering, gaat het niet door dan verwijder je het record gewoon.
Verder is PostgreSQL een goeie keuze als je daar de beschikking over hebt; let alleen wel op dat je alleen wat hebt aan foreign key constraints als je ze ook daadwerkelijk definieert.

[ Voor 6% gewijzigd door Pelle op 08-01-2003 03:46 ]

[Mx. Alba]

Ik ben het inderdaad eens met Pelle. Je moet per kamer bijhouden wanneer deze bezet is. Als een kamer voor een bepaalde periode vrij is, wordt daar een bewoner bij gezocht. Ik neem aan dat er een wachtlijst is, dus dat in principe eigenlijk nooit kamers vrijstaan, waardoor dat systeem het efficiëntst is.

Maar wat je ook moet besluiten (hoewel ik niet weet of je dat in jouw software wilt bouwen) is de mate van efficiëntie die je wilt hebben. In welke mate is het gewenst dat een kamer bijvoorbeeld enkele weken of een maand onbezet is, om iemand met een hogere prioriteit een kamer te kunnen geven?

Wat ik bedoel is, stel dat een kamer vanaf week 32 vrij is, en dat iemand in de hoogste prioriteitsklasse een kamer nodig heeft vanaf week 37. Maar er is ook iemand een prioriteitsklasse of 2 lager die vanaf week 32 een kamer nodig heeft. Geef je hem aan die eerste persoon, waardoor de kamer een maand leegstaat, of geef je hem aan de tweede persoon om de bezetting te optimaliseren?

En wat als die tweede persoon eigenlijk al vanaf week 25 een kamer nodig had?

[ Voor 4% gewijzigd door Mx. Alba op 08-01-2003 07:53 ]

[Infern0]

Alvast bedankt voor de tips. Ik denk dat ik me wel in het idee kan vinden dat een aanbiedingstabel een beetje overbodig is. Ik had hem eraan toegevoegt omdat ik d8 dat het handig was voor het overzicht, maar je slaat in principe dubbele data op en dat is idd niet handig. Mocht de reservering alsnog niet doorgaan, dan kan hij alsnog uit de reservering tabel gehaald worden en naar de afwijzing tabel getransporteerd worden.

Verder even over het inplannen. Het systeem heeft geen initilligentie nodig (gelukkig), dus de hele inplanning van kamers gebeurd door de gebruiker. Verder is het hier voor buitenlandse studenten zo dat er een kamerleegstand is (ja 10%....), daarom deze werkwijze.

Verder werden door mijn opdrachtgevers 1001 dingen aangedragen waarom student X wel voor kamer Y in aanmerking komt en student Z niet. Al deze aanmerkingen zijn niet in een DB te stoppen (aantal wel) en daarom deze handmatige manier.

[whoami]

Zou dit niet beter thuishoren in P&W?
Denk dat je daar meer respons zult krijgen...

[Infern0]

Wat mij betreft wel. Ik heb het hier geplaatst omdat niet wist of dit wel van voldoende hoog niveau zou zijn. Kom nl niet zo vaak in P&W. Maar als de P&W mods dit wel vinden, mag die van mij gemoved worden.

[Jaymz]

A61 => P&W