[mysql] reserveringen in tabel selecteren

[hobbeldebobbel]

hoi ik zoek een query die uiteindelijk moet aangeven in een reserveringssysteem dat een hotelkamer bezet is danwel vrij is.

ik heb een tabel met daarin de reserveringen van de kamers en bestaat uit de velden:

code:

id(int) || van(datetime) || tot(datetime)

ik heb nu een mooi schema gemaakt in html/php welke per dag en kamer gaat kijken of de ochtend dan wel de middag bezet is.
ik ga dus voor iedere dag twee keer bekijken of er een ochtend dan wel avond reservering is (of beiden)

De incheck tijd is vanaf 1500, uitchecken moet voor 11:00

Ik was tot zover gekomen dat mensen die reserveren op precies die tijden, dat die goed weer worden gegeven, maar helaas als mensen pas om 17 inchecken worden niet weer gegeven....
mijn code:

PHP:

$pijl = "20070915150000";
$sql = "SELECT * FROM HMS_hotel 
WHERE kamid = '".$kamer['id']."' 
AND  (
tot >= '".$pijl."'
AND
van <= '".$pijl."'
)";

dit gaat dus goed voor mensen die om precies 15:00 gereserveerd hebben. Maar als iemand aangeeft om 17:00 te komen dan word het niet goed weergegeven.

zou iemand mij kunnen helpen?

[Creepy]

Eeeh... pak een andere tijd voor tot? Je gebruikt nu dezelfde tijd voor zowel van en tot. Lijkt me logisch dat dat alleen werkt als precies die tijd voorkomt. Nofi maar of ik begrijp je niet of dit is echt enorm simpel.

[Verwijderd]

Spaar je de moeite...
Zelfs die morgen/middag opsplitsing in het roomrack uit je link is al teveel van het goede.

Een hotel werkt met kamernachten en de checkin of checkout tijd boeit voor het roomrack niet of nauwelijks. Enige uitzondering zijn day use kamers, maar ik neem aan dat je deze software niet schrijft voor "hotels" met de nadruk op peeskamertjes? Daar is geen markt voor...

Die afzonderlijke selects per kamer/van/tot gaan je waarschijnlijk qua performance ook nogal opbreken. Misschien nog goed te doen bij een 20-kamer hotelletje en een rack van 2 weken, maar 20-kamer hotelletjes hebben meestal niet de meest up-to-date hardware.

Je zult op z'n minst de hele range in 1 select moeten inlezen, en die in een eigen object/array/whatever structuur moeten zetten om een beetje performance te krijgen. En bij grotere hotels (zeg vanaf bv. 100 kamers) is 't dan zelfs aan te raden om een extra roomrack tabel bij te houden met bezettingsgegevens per kamer per dag.

Over m'n "spaar je de moeite" beginregel:
Toen we in '95 overgingen van textbased naar grafische weergave van 't roomrack, hebben we ook flink uitgepakt met grafisch tonen van CI en CO tijden, etc. Zag er fantastistisch uit!
3 jaar later hebben we een optie ingebouwd (op verzoek van een aantal klanten) om iedere kolom in 't roomrack gewoon voor een overnachting te laten gelden.

En ondertussen is er niet 1 van onze 600+ klanten die nog voor de oude optie kiest...

[hobbeldebobbel]

creepy: ja shit hej ik was meer weer eens blind aan het staren op een andere oplossing voor een soortgelijk probleem, met als gevolg dat ik niet meer keek naar wat ik nou eigenlijk wilde. maar goed inderdaad een $pijl2 is de oplossing.

afterlife:
bedankt voor je zeer nuttige informatie ik heb hier met de expert van hotel-software te maken lees ik zo snel even
Het is inderdaad voor een klein hotelletje: 13kamers met geen optieom uit te breiden. De rack voor alsnog is inderdaad voor slechts twee weken. Dus kwa hoeveelheden zal het denk ik wel meevallen toch?
maar het alles in 1 select ophalen bedoel je dan gewoon alle gegevens van de reserveriingen in een bepaald tijdspanne en dan in php bekijken wat er mee te doen? Want dan verplaats je toch enkel het zwaartepunt, van afzonderlijke querys naar afzonderlijke vergelijkingen in php?

De eigenaren van het hotel zijn nogal grafisch ingesteld, is een oud-interieurarchitect en wil in 1 oogopslag veel gegevens zien, heb hem ook voorgelegd inderdaad om 1 kolom per dag/nacht te laten zien maar dit vond ie leuker en 'makkelijker'... en tja klant is koning toch

over de peeskamertjes..... er komt 1 kamertje met een uren verhuur: de wellness room die wel per uur te reserveren is maar dat komt in een andere tabel

[Verwijderd]

hobbeldebobbel schreef op woensdag 12 september 2007 @ 10:50:
bedankt voor je zeer nuttige informatie ik heb hier met de expert van hotel-software te maken lees ik zo snel even

'De' expert is wat teveel gezegd, maar ik werk al dik 10 jaar als ontwikkelaar voor een bedrijf dat uitsluitend software voor de hotel-branche ontwikkelt. En daarvoor ben ik 12 jaar systeembeheerder in een redelijk groot hotel (450 kamers, 25 zalen) geweest, dus helemaal onervaren met de materie ben ik niet...

Het is inderdaad voor een klein hotelletje: 13kamers met geen optieom uit te breiden. De rack voor alsnog is inderdaad voor slechts twee weken. Dus kwa hoeveelheden zal het denk ik wel meevallen toch?

Met 13 kamers is performance idd geen issue. Maar 't zou zonde zijn als je PMS (property management system) niet schaalbaar zou zijn naar properties met meer kamers.

maar het alles in 1 select ophalen bedoel je dan gewoon alle gegevens van de reserveriingen in een bepaald tijdspanne en dan in php bekijken wat er mee te doen? Want dan verplaats je toch enkel het zwaartepunt, van afzonderlijke querys naar afzonderlijke vergelijkingen in php?

Ja en nee. Veel kleine queries zijn duur, zeker wanneer de queries niet geparameteriseerd zijn: je database ziet dan iedere query als een query die 'ie nog nooit eerder heeft gezien en kan dan z'n statistics niet goed bijwerken of een execution plan optimaliseren. (weet overigens niet of MySQL die dingen ondersteunt).
Bovendien heb ik begrepen dat de combinatie PHP/MySQL voor iedere query een nieuwe connection met de database moet opbouwen, en dat is ook niet echt gratis.

Maar waar 't echt om gaat: met de juiste indexen zal 1 range query waarschijnlijk 100x sneller zijn dan 13 x 14 queries. En in die overblijvende tijd kan PHP met z'n vingers in de neus probleemloos een array opbouwen waarmee je je rack kunt opbouwen.

De eigenaren van het hotel zijn nogal grafisch ingesteld, is een oud-interieurarchitect en wil in 1 oogopslag veel gegevens zien, heb hem ook voorgelegd inderdaad om 1 kolom per dag/nacht te laten zien maar dit vond ie leuker en 'makkelijker'... en tja klant is koning toch

Is dat screenshot het definitieve ontwerp voor het rack? Ziet er netjes uit, maar ik mis een paar dingen... (opbouwend bedoeld hoor!)
- Onderscheid tussen uitgecheckt, gast in huis en reservering (kleurtjes doen wonderen)
- Onderscheid tussen zelfde gast als de vorige nacht of een nieuwe gast (housekeeping en front desk zullen je dankbaar zijn!)
- Wanneer je die dagdeel-blokjes aan elkaar knoopt, kun je er ook de naam van de gast in kwijt, en dat is gewoon heel erg handig, zeker in een klein hotel. (grotere hotels plannen niet vanaf het roomrack)

er komt 1 kamertje met een uren verhuur: de wellness room die wel per uur te reserveren is maar dat komt in een andere tabel

Ga je het wellness stuk ook zelf schrijven? Dat is bijna een vak opzich! Met 1 wellness room zal 't wel meevallen, maar een 'echt' wellness systeem heeft te maken met interfaces naar kassa's, inplanning personeel, en nog veel meer dingen.
Maar dan heb ik 't meer over bv. Thermae 2000, en niet over 1 wellness room.
(Niet dat we Thermae's wellness hebben gedaan overigens, wel het hotel en de koppelingen naar het 'natte' gedeelte.)

[hobbeldebobbel]

Verwijderd schreef op woensdag 12 september 2007 @ 20:21:

Met 13 kamers is performance idd geen issue. Maar 't zou zonde zijn als je PMS (property management system) niet schaalbaar zou zijn naar properties met meer kamers.

de hoeveelheid kamers heb ik nu in een tabel staan en die kan ik dus uitbreiden dan wel inkrimpen mocht iemand anders geinteresseerd zijn in het systeem... maar ik ben niet van plan om het systeem te gaan verkopen aan grote hotels... daar hebben ze mooi jullie voor!

[...]
Ja en nee. Veel kleine queries zijn duur, zeker wanneer de queries niet geparameteriseerd zijn: je database ziet dan iedere query als een query die 'ie nog nooit eerder heeft gezien en kan dan z'n statistics niet goed bijwerken of een execution plan optimaliseren. (weet overigens niet of MySQL die dingen ondersteunt).
Bovendien heb ik begrepen dat de combinatie PHP/MySQL voor iedere query een nieuwe connection met de database moet opbouwen, en dat is ook niet echt gratis.

Maar waar 't echt om gaat: met de juiste indexen zal 1 range query waarschijnlijk 100x sneller zijn dan 13 x 14 queries. En in die overblijvende tijd kan PHP met z'n vingers in de neus probleemloos een array opbouwen waarmee je je rack kunt opbouwen.
[...]

hmm okay daar ga ik even een nachtje over nadenken en implementeren...

Is dat screenshot het definitieve ontwerp voor het rack? Ziet er netjes uit, maar ik mis een paar dingen... (opbouwend bedoeld hoor!)

alle input is welkom en dat meen ik echt serieus.. daar word het produkt uiteindelijk alleen maar beter van nietwaar!

- Onderscheid tussen uitgecheckt, gast in huis en reservering (kleurtjes doen wonderen)

heb nu gewerkt met verschillende nuances van de kleuren... donker:ingechecked, midden gereserveerd en licht vrij. Misschien dat ik toch voor wat fellere kleuren moet gaan.. maar dat verpest de insteek van rust en overzicht...

- Onderscheid tussen zelfde gast als de vorige nacht of een nieuwe gast (housekeeping en front desk zullen je dankbaar zijn!)

- Wanneer je die dagdeel-blokjes aan elkaar knoopt, kun je er ook de naam van de gast in kwijt, en dat is gewoon heel erg handig, zeker in een klein hotel. (grotere hotels plannen niet vanaf het roomrack)

de bedoeling is om dadelijk iets te maken dat als je met je muis erover heen gaat dat je dan meer info krijgt te zien. En dat als je hovert zeg maar dat dan de dagen van de betreffende gast gaat oplichten of iets dergelijks...moet ik nog even over na denken

[...]
Ga je het wellness stuk ook zelf schrijven? Dat is bijna een vak opzich! Met 1 wellness room zal 't wel meevallen, maar een 'echt' wellness systeem heeft te maken met interfaces naar kassa's, inplanning personeel, en nog veel meer dingen.
Maar dan heb ik 't meer over bv. Thermae 2000, en niet over 1 wellness room.
(Niet dat we Thermae's wellness hebben gedaan overigens, wel het hotel en de koppelingen naar het 'natte' gedeelte.)

jups... ga ik ook doen, maar bij deze is het heel eenvoudig... 1 ruimtetje maar..... moet even kijken hoe gedetaileerd enzo... eerst het hotel gedeelte dan de rest

bedankt overigens voor je input! waardeer ik enorm!

[Verwijderd]

hobbeldebobbel schreef op woensdag 12 september 2007 @ 22:19:
heb nu gewerkt met verschillende nuances van de kleuren... donker:ingechecked, midden gereserveerd en licht vrij. Misschien dat ik toch voor wat fellere kleuren moet gaan.. maar dat verpest de insteek van rust en overzicht...

Klinkt bekend! De kleuren voor de verschillende statussen (uitgecheckt, in huis, reservering, out of order, out of inventory) zijn bij ons instelbaar, en je wil niet weten wat voor kerstboom gebruikers daarvan weten te maken...

de bedoeling is om dadelijk iets te maken dat als je met je muis erover heen gaat dat je dan meer info krijgt te zien. En dat als je hovert zeg maar dat dan de dagen van de betreffende gast gaat oplichten of iets dergelijks...moet ik nog even over na denken

Leuk idee, maar ik zou 't niet doen.
Wanneer een receptionist(e) moet hoveren om extra informatie te krijgen, gaat zijn/haar blik en aandacht naar het beeldscherm, en niet naar de gast die aan de balie staat. Als die informatie al direct op 't scherm staat hoeft de receptionist(e) geen extra handeling te verrichten, en kan meer aandacht aan de gast voor de balie worden besteed. En daar draait 't om in de hotellerie.

bedankt overigens voor je input! waardeer ik enorm!

YW!

[hobbeldebobbel]

ok ik zit er al een hele tijd mee te boksen om het allemaal in 1 query te krijgen, of in ieder geval in zo min mogelijk queries.
Daarnaast heb ik alles omgebouwd van een tabel structuur naar een divjes structuur met een variabele breedte.

De opzet per regel is als volgt wat ik bedacht had:

code:

<div class='regel'>
<div class='blanco' style='width:90px;'>//drie dagdelen vrij
---
</div>
<div id='res-346' style='width:180px'>//zes dagdelen gereserveerd
Dhr Jansen
</div>
<div class='blank' style='width:150px'>//vulling van 5 dagdelen
---
</div>
</div>

dat is de opzet om het grafisch te maken. Ik weet niet of hier commentaar op is... en of ik een veel makkelijkere manier over het hoofd zie.

Nu komt dan het uit de database halen van de juiste gegevens. De dagen die getoond moeten worden staan in de array $dagen. $dagen[0] is de eerste dag=$begin en end($dagen) is de laatste dag=$eind. En die zijn als volgt opgebouwd: YYYYMMDD

ik kom tot deze sql-query:

SQL:

SELECT *, 
      DATEDIFF(van, tot) AS duur, 
      DATEDIFF(van, ".$begin.") as afstandbegin,
      HOUR(van) as beginuur,
      DATE_FORMAT(van, '%Y%m%d%T') AS vanDB,
      DATE_FORMAT(tot, '%Y%m%d%T') AS totDB
                          
      FROM 
            HMS_hotel 
       WHERE 
             kamid=1 
        AND
             van <= $eind
         AND 
              tot >= $begin

so far so good.. hij haalt nu de reserveringen op die binnen het gepresenteerd tijdvak een overlap hebben.
Wat me nu niet lukt is om deze query om te zetten in een roomrack opgebouwd uit divjes.... en zeker niet als er bij komt dat ik 'halve' dagen gebruik

iemand een heldere ingeving zo vroeg op de avond

[ Voor 7% gewijzigd door hobbeldebobbel op 13-09-2007 20:54 ]

[Verwijderd]

Mijn PHP kennis is ongeveer 0,0, dus ik houd 't algemeen...
Ik zou beginnen met een object-lijst waar je het resultaat van je query in opslaat, en een lege matrix van 13 kamers en 28 dagdelen. Vervolgens vul je die matrix aan de hand van die objectlijst, waarbij iedere cel die binnen een bep. reservering valt (kamernummer/dagdeel) een verwijzing krijgt naar die reservering in de objectlijst.
Die gevulde matrix kun je dan gebruiken om de divs van je roomrack op te bouwen.

In de praktijk zetten wij die cellen in de matrix al van tevoren in een eigen tabel, middels triggers op de reserveringen tabel. 't Is niet "netjes" (redundante data en zo), maar een roomrack moet binnen een halve seconde op het scherm staan. Bij een klein hotel lukt dat op bovenstaande manier prima, maar bij 400 kamers of zo wordt 't echt een probleem...

[hobbeldebobbel]

ok daar ga ik eens even over verder denken..want zo 1 twee drie lukt het me niet.. als iemand nog een goede ingeving heeft....ik hou me aanbevolen.