[Access 2003] Voorkomen dubbele combinatie data/lokatie

[Wacky]

Wellicht een vage topictitel maar het zit zo:

Voor school moet ik een informatiesysteem maken voor een camping in Access 2003.

Nu zit ik met een probleem: hoe voorkom ik dubbele boekingen van een lokatie?
Bij voorkeur los ik dit op met een constraint, maar hoe

Mijn tabel 'Reserveringen' ziet er als volgt uit:

code:

PK  ReserveringsNr
FK  LokatieNr
FK  GastNr
    StartDatum
    EindDatum
    Betaald

Het gaat er dus om hoe ik voorkom dat bijvoorbeeld de lokatie met nummer 5 overlappende reserveringsdata krijgt (dus dat de begindatum van een reservering VOOR de einddatum van een andere reservering met hetzelfde lokatienummer ligt).

Wie o wie kan mij helpen

[ Voor 17% gewijzigd door Wacky op 05-05-2005 21:28 ]

[Boss]

Hier zijn verschillende manieren voor. Wat het beste is hangt een beetje af van hoe de gebruiker een reservering zou willen invoeren. En naar mate je verder met Access bent zou je het ook wat geavanceerder kunnen maken.

De eerste en meest makkelijke optie is om slechts per plek en per tijd te controleren of er plaats is. Dat kan je doen door voordat de reservering wordt opgeslagen via bijvoorbeeld de functie DCOUNT() te controleren of er al een boeking is binnen die datum/tijd.

Een volgende stap zou zijn om tijdens het invoegen van een reservering al direct een overzicht te maken van de plaatsen die vrij zijn, en die via een soort tijdbalk weergeven (rood = bezet, groen = vrij, oranje = resereve ofzo). De persoon die dan de boeking aanneemt kan op het moment van boeken al meteen zien wat er nog vrij is in de betreffende periode.

Mijn ideale situatie zou zijn: voer start / einddatum in en geef een overzicht van alle plaatsen die nog vrij zijn. Eventueel een x-aantal dagen voor/na kunnen opgeven zodat je de klant ook kan vertellen dat als hij een dag eerder / later komt dat ene mooie plekje wel vrij is.

Maarja... het is voor school. Hangt een beetje van de opdracht af hoe ver je hiermee moet gaan

[Wacky]

Poeh, dit gaat mijn access pet even te boven

Desondanks bedankt, ik ga eens even heftig googlen op dcount

Wat je zeft over dat overzicht van al die plaatsen, hoe kan ik een overzicht maken met dan daarachter een knop dat verwijst naar een formulier en dan ook nog het gekozen lokatienummer meegeeft?

Je merkt het al, ik ben niet zo'n access held. Jammergenoeg stellen ze op school allerlei eisen die niet echt direct opleidingsgerelateerd zijn. Ik doe Bedrijfskundige Informatica en het vak waaronder Access valt (systeemontwikkeling) gaat er eigenlijk meer over dat je weet wat een database is en hoe het werkt

Edit:

Ik heb nu een controle query gemaakt, die het goed schijnt te doen

code:

SELECT Lokaties.LokNr, Groottes.GrootteType, Soorten.SoortNaam, Lokaties.LokPrijs, Lokaties.LokStroom, Lokaties.LokWater, Lokaties.LokKabelTV
FROM Soorten INNER JOIN (Groottes INNER JOIN Lokaties ON Groottes.GrootteNr = Lokaties.GrootteNr) ON Soorten.SoortNr = Lokaties.SoortNr
WHERE (((Lokaties.LokNr) Not In (SELECT LokNr FROM Reserveringen
where ResDatumStart < [datum]
AND ResDatumEind > [datum])));

Nu verder implementeren

[ Voor 31% gewijzigd door Wacky op 05-05-2005 22:15 ]

[Boss]

Oooohhh... dan zou ik het allemaal niet zo moeilijk maken.

Met dcount() kan je records tellen die aan een bepaalde voorwaarde voldoen:

Visual Basic:

if dcount("kolom","tabel","criterium") > 1 then
  'er is al een reservering voor deze plek, waarschuwing & afbreken
else
  'er is nog geen reservering voor deze plek, opslaan
end

Alleen het stukje bij criteria is even lastig. Je moet filteren op de gekozen plek, en start/einddatum van de nieuwe reservering mogen niet overlappen met die van een bestaande. Dat zou je met de SQL functie BETWEEN wel moeten kunnen vinden.

[Verwijderd]

Troost je, er zijn mensen die al 8 jaar aan dit soort reserveringssystemen werken (ikke ) en nog steeds naar de echt ideale oplossing zoeken.

Via een constraint ga je 't niet redden, tenzij je in een extra tabel per dag / locatie gaat bijhouden of die locatie bezet is, en door wie (ReserveringsNr). Bij een volwassen database kun je die extra tabel laten bijhouden door triggers op je Reserveringen tabel, maar ik betwijfel of dat met Access ook kan.

Die extra tabel wordt overigens door vrijwel ieder hotel reserveringssysteem gebruikt (ook om performance redenen), dus zo gek is dat niet.

Mijn ideale situatie zou zijn: voer start / einddatum in en geef een overzicht van alle plaatsen die nog vrij zijn. Eventueel een x-aantal dagen voor/na kunnen opgeven zodat je de klant ook kan vertellen dat als hij een dag eerder / later komt dat ene mooie plekje wel vrij is.

Zou ook mijn ideale situatie zijn, alleen denken de hoteliers en campingbeheerders daar anders over...
Als je een aanvraag krijgt voor 'dat ene mooie plekje', en die is al gereserveerd voor iemand die 'gewoon een plek' zocht, moet je op dat moment die bestaande reservering kunnen verhuizen naar een andere 'gewone plek' en dan de nieuwe reservering kunnen aannemen. En da's nog maar het topje van de ijsberg van problemen en dilemma's die je tegen kunt komen...

[Verwijderd]

Wacky schreef op donderdag 05 mei 2005 @ 21:55:

code:

SELECT Lokaties.LokNr, Groottes.GrootteType, Soorten.SoortNaam, Lokaties.LokPrijs, Lokaties.LokStroom, Lokaties.LokWater, Lokaties.LokKabelTV
FROM Soorten INNER JOIN (Groottes INNER JOIN Lokaties ON Groottes.GrootteNr = Lokaties.GrootteNr) ON Soorten.SoortNr = Lokaties.SoortNr
WHERE (((Lokaties.LokNr) Not In (SELECT LokNr FROM Reserveringen
where ResDatumStart < [datum]
AND ResDatumEind > [datum])));

Ik heb geen enkele ervaring met Access, maar zijn die beide [datum] parameters hetzelfde? Zo ja, dan werkt 't soms een beetje voor 1-daagse reserveringen. Alleen vang je dan niet af dat er al een reservering kan zijn voor die locatie die op dezelfde dag aankomt...

where ResDatumStart < [einddatum] and ResDatumEind >= [startdatum]

moet een stuk beter werken om de overlappende reserveringen eruit te vissen.

[Wacky]

Verwijderd schreef op donderdag 05 mei 2005 @ 22:51:
[...]

Ik heb geen enkele ervaring met Access, maar zijn die beide [datum] parameters hetzelfde? Zo ja, dan werkt 't soms een beetje voor 1-daagse reserveringen. Alleen vang je dan niet af dat er al een reservering kan zijn voor die locatie die op dezelfde dag aankomt...

where ResDatumStart < [einddatum] and ResDatumEind >= [startdatum]

moet een stuk beter werken om de overlappende reserveringen eruit te vissen.

Klopt, niet bij stilgestaan. Ik heb het nu gemaakt zoals jij aangaf.

Nu nog iets maken waardoor de beschikbare lokaties ook gereserveerd kunnen worden d.m.v. het meegeven van het lokatienummer

[Boss]

Verwijderd schreef op donderdag 05 mei 2005 @ 22:37:
Die extra tabel wordt overigens door vrijwel ieder hotel reserveringssysteem gebruikt (ook om performance redenen), dus zo gek is dat niet.
[...]

Een tabel met voor iedere kamer (of plek of andere resource) per dag bijgehouden of de kamer vrij of niet is? Lijkt me nodeloos complex, hoewel het inderdaad wel wat in performance zal schelen. Met een paar redelijk eenvoudige queries is het toch net zo makkelijk op te lossen?

Ik denk dat jet met zo'n tussentabel veel meer problemen krijgt bij het wijzigen van een boeking. Moet je ipv 1 record alle records aanpassen waar de wijziging betrekking op heeft.

ff uit nieuwschierigheid: waar werk je dan als je al 8 jaar aan zo'n systeem aan het werken bent?

[ Voor 7% gewijzigd door Boss op 05-05-2005 23:20 ]

[Verwijderd]

Boss schreef op donderdag 05 mei 2005 @ 23:19:
Een tabel met voor iedere kamer (of plek of andere resource) per dag bijgehouden of de kamer vrij of niet is? Lijkt me nodeloos complex, hoewel het inderdaad wel wat in performance zal schelen. Met een paar redelijk eenvoudige queries is het toch net zo makkelijk op te lossen?

Neem jouw voorbeeld: rood = bezet, groen = vrij en geel is gereserveerd.
Da's prima in een paar slimme queries op te halen, maar wanneer 't gaat om 500+ kamers en een periode van 3 of 4 weken, dan duurt 't even voordat je het hele grid gevuld hebt. En die tijd kun je je niet veroorloven wanneer er een telefonische reservering binnenkomt of wanneer je een webreservering aanvraag binnenkrijgt waarop je binnen een seconde moet reageren of 't wel of niet kan.

Overigens kost het bijhouden van die tussentabel erg weinig tijd, en wordt dat via triggers op de database geregeld. De extra tijd dat het kost om die tabel bij te houden staat in geen verhouding tot de extra tijd die 't kost wanneer die tabel NIET gebruikt zou worden.

Voorbeeld: bij hotelreserveringen via internet heb je een 'look to book' verhouding van minimaal 500:1. Oftewel, tegenover 500 aanvragen van o.a. beschikbaarheid (die je uit die tussentabel haalt) staat 1 reservering (die die tussentabel aanpast).

Dit is heel simplistisch voorgesteld, maar geeft wel een beetje aan waar je rekening mee moet houden.

ff uit nieuwschierigheid: waar werk je dan als je al 8 jaar aan zo'n systeem aan het werken bent?

Bij een bedrijf dat software voor hotels en aanverwante bedrijven maakt. Nu zo'n 400 hotels in Nederland, Belgie, Duitsland, Frankrijk, Italie, VS, Australie en Canada, en nog steeds groeiende.

Geloof me, er is geen enkel reserveringssysteem voor hotels dat "af" is. Die markt ontwikkelt zich nl. continu, en stelt steeds nieuwe eisen. 8 jaar is dan zelfs nog vrij kort...