Databaseontwerp campingsite

[Verwijderd]

Goededag,
Momenteel sta ik op het punt om een nieuwe website te bouwen. Graag jullie advies en tips!
Het is de bedoeling dat er een website komt waar stacaravans worden aangeboden. Heeft een willekeurig persoon een stacaravan dan kan hij zich wenden tot de beheerders van de website. Deze kunnen dan 3 foto’s, een omschrijving, een koppeling naar de camping, de beschikbare weken, het maximaal aantal personen en de prijs uploaden. Deze gegevens komen, van zelf sprekend, in een database te zitten.
De andere kant van de website.
Iemand die op vakantie wil naar camping X komt via een advertentie op de website. Hij geeft het volgende op: hoeveel personen minimaal, welke camping, en waneer hij op vakantie wil. Vervolgens gaat php aan het rekenen met de ingevulde gegevens uit de MySql database. En presenteert de uitkomst aan de ‘aankomend vakantieganger’. Bovenaan worden de caravans weer gegeven waar zijn eerste keus naar uitgaat en daaronder caravans die wel beschikbaar zijn maar niet op zijn camping.
Nu heb ik wel ervaring met websites die werken met een database, maar dit is net één trap hoger. Het hele gebeuren zie ik wel zitten. Alleen, hoe kan ik de weeknummers er het beste in fietsen? Dit zie ik voor me als db ontwerp:

Camping	Caravan	Klant
Camping_id Camping_plaats Camping_omschijving Camping_foto_id1 Camping_foto_id2 Camping_foto_id3 Camping_URL1 Camping_URL2	Caravan_id Camping_id Max_personen Caravan_omschijving Caravan_foto_id1 Caravan_foto_id2 Caravan_foto_id3 Caravan_prijs Week_1_1jan-7jan2008 (waarde 1 of 0) Week_2_7jan-14jan2008 (waarde 1 of 0) Week_3_14jan-21jan2008 (waarde 1 of 0) Enz.	Id Naam Adres Postcode Plaats Email Caravan_id Weeknummer1???? Weeknummer2???? Weeknummer3???? Weeknummer4???? Weeknummer5???? Weeknummer6???? Weeknummer7???? Weeknummer8????

Graag hoor ik jullie reactie!

[zwippie]

Je moet zien te voorkomen dat je voor elke week een kolom maakt, dat is gewoon not done. Beter is het om een koppeltabel voor reserveringen te maken, iets als:

Reservering
Caravan_id
Klant_id
Weeknummer

En een Caravan_id hoort ook niet echt in de tabel klant, maar bij een reservering.
Eventueel kun je eerst nog een tabel maken met alleen alle weeknummers met bijbehorende van/tot data erin, maar dat zou je ook steeds on-the-fly kunnen berekenen.

[NMe]

zwippie schreef op woensdag 17 oktober 2007 @ 11:06:
Eventueel kun je eerst nog een tabel maken met alleen alle weeknummers met bijbehorende van/tot data erin, maar dat zou je ook steeds on-the-fly kunnen berekenen.

De indeling in de topicstart is vooral ook lastig als iemand langer dan een week wil blijven (want dat zou meerdere records voor één reservering betekenen) of zelfs als iemand korter wil blijven (als je niet weet wanneer iemand aankomt/weggaat is dat lastig als je ze ter plekke nodig hebt om iets te tekenen bijvoorbeeld).

[Janoz]

Zodra je in je kolomnamen begint te nummeren danwel op te sommen ben je fout bezig. Dit is gewoon een 1:N relatie en hoor je in een apparte tabel te stoppen met een ID naar de hoofd tabel. Dit geld niet alleen voor de weeknummers, maar ook voor de weekomschrijving in de caravan tabel en eventueel zelfs voor de foto_id. Die vind ik sowieso vreemd. Waarom zet je in camping een foto_id? Veel makkelijker is om in foto gewoon een camping_id op te nemen. Dan heb je die beperking van 3 ook niet meer mocht je later ooit nog eens meer foto's toe willen staan.

[Verwijderd]

Komt dit beter in de buurt?

Camping	Caravan	Klant	Reservering	Foto
Camping_id Camping_plaats Camping_omschijving Camping_URL1 Camping_URL2	Caravan_id Camping_id Max_personen Caravan_omschijving Caravan_prijs	Klant_id Naam Adres Postcode Plaats Email	Caravan_id Klant_id Weeknummer	Foto_id Camping_id Caravan_id Foto_URL Foto_width Foto_height

Nu zit ik alleen met de weken. Het is de bedoeling dat, voor als nog, er alleen weken van vrijdag tot vrijdag geboekt kunnen worden. Misschien in te toekomst ook rond feestdagen. Bijvoorbeeld hemelvaart weekend.
Niet elke caravaan is 52 weken per jaar beschikbaar. Sommige misschien maar 5 weken. Kortom, wat is het handigst/best voor de beschikbaarheid?

[ Voor 1% gewijzigd door Verwijderd op 17-10-2007 11:58 . Reden: Foutje weg gepoetst ]

[Janoz]

Als je daarop voorbereid wilt zijn dan zul je niet met weken, maar met dagen moeten gaan werken in de database. Het gebruik van dagen zorgt wel voor een boel records maar is in de afhandeling makkelijker. je kunt ook begin en eind tijden gebruiken. Dit is in principe wel netter, maar maakt de code voor het boeken wat lastiger. De beschikbaarheid kun je natuurlijk op een zelfde soort manier oplossen als de reserveringen.

[Verwijderd]

Begrijp ik het goed dat jullie dit zeggen:

Camping	Caravan	Klant	Reservering	beschikbaar	Foto
Camping_id Camping_plaats Camping_omschijving Camping_URL1 Camping_URL2	Caravan_id Camping_id Max_personen Caravan_omschijving Caravan_prijs	Klant_id Naam Adres Postcode Plaats Email	Caravan_id Klant_id Begintijd/datum Eindtijd/datum	Caravan_id Begintijd/datum Eindtijd/datum	Foto_id Camping_id Caravan_id Foto_URL Foto_width Foto_height

Als ik het zo oplost dan zie ik een volgend probleem. Als een caravan 5 weken beschikbaar is, en week 2 en 3 worden geboekt. Dan doet hij het net meer zoals hier boven staat. Of je moet voor elke dag een record maken... × aantal caravan's. Dat betekend een heleboel data. Is er geen efficentere manier?

[Janoz]

Waarom zou hij het niet meer doen? Met een beetje extra logica in de business laag van je applicatie los je dat zo op. Zoals ik al zei, de nu door jou geposte oplossing is netter, maar de code voor het boeken is wat ingewikkelder terwijl voor elke dag een record maken makkelijker werkt, maar een onhandigere database oplevert.

[ Voor 17% gewijzigd door Janoz op 17-10-2007 12:08 ]

[Verwijderd]

Sorry, maar ik sanp het niet helemaal wat je bedoelt.

De oplossing die ik gepost heb is netter zeg je met een ingewikkelde code. Stel de caravan is van af week 1 tot en met week 3 beschikbaar. in de database staat dan:

begindatum/tijd:1jan/17:00uur
einddatum/tijd:21jan/10:00uur

Als ik nu week 2 boek.Dan staat in de database bij reservering:

begindatum/tijd:7jan/17:00uur
einddatum/tijd:14jan/10:00uur

Moet ik dan het PHP script zo maken dat hij de beschikbaarheid wist, een reservering maakt, en de overgebleven weken opnieuw in de tabel beschikbaar zet? Op den duur wordt dit toch ook een zootje?

[Janoz]

Bijna. De beschikbaarheids tabel moet je alleen gebruiken om aan te geven wanneer de eigenaar zijn caravan in de verhuur heeft. De uiteindelijke beschikbaarheid is af te leiden uit de beschikbaarheid gecombineerd met de reserveringen. Dat moet je inderdaad in je php controleren. Met php ga je vervolgens niet de beschikbaarheid aanpassen.

[Verwijderd]

Oké, bedankt. Ik ga het probeeren te maken.
Is de het ontwerp van de database zo correct?

[Croga]

Verwijderd schreef op woensdag 17 oktober 2007 @ 14:11:
Oké, bedankt. Ik ga het probeeren te maken.
Is de het ontwerp van de database zo correct?

Persoonlijk zou ik de tijd uit de reserverings/beschikbaarheids tabel halen en simpelweg stellen dat iemand vanaf 15:00 (of 17:00 whatever) er in kan en om 11:00 (of 9:00 whatever) er weer uit moet zijn. Zo wordt het over het algemeen in Hotels gedaan en het maakt alles een stuk eenvoudiger.

[GrooV]

Croga schreef op woensdag 17 oktober 2007 @ 14:18:
[...]

Persoonlijk zou ik de tijd uit de reserverings/beschikbaarheids tabel halen en simpelweg stellen dat iemand vanaf 15:00 (of 17:00 whatever) er in kan en om 11:00 (of 9:00 whatever) er weer uit moet zijn. Zo wordt het over het algemeen in Hotels gedaan en het maakt alles een stuk eenvoudiger.

Dit kan je in de business laag oplossen, stel dat mensen tot 5 uur smiddags willen blijven. Het beste is je database zo uitgebreid mogelijk te hebben om later niet tegen beperkingen aan te lopen

[Croga]

GrooV schreef op woensdag 17 oktober 2007 @ 14:41:
Dit kan je in de business laag oplossen, stel dat mensen tot 5 uur smiddags willen blijven. Het beste is je database zo uitgebreid mogelijk te hebben om later niet tegen beperkingen aan te lopen

Waarom zou je geld gaan stoppen in iets te ontwikkelen waarvan je weet dat je het niet nodig hebt? Als mensen tot 5 uur willen blijven dan spreek je dat bij de receptie af en dan is het opgelost.

Idealisme van "zo uitgebreid mogelijk maken" is leuk maar zakelijk gezien is pragmatisme in deze een stuk nuttiger.

[ Voor 10% gewijzigd door Croga op 17-10-2007 14:46 ]

[Verwijderd]

Moet er niet een tijd aan zitten? Want als ik smorgens vertrek zit er smiddags al iemand anders.

Ik bedoel, als php gaat kijken of het nog beschikbaar is en er staat in de BD:

Beschikbaar
begindatum/tijd:1jan/16:00uur
einddatum/tijd:21jan/10:00uur

reservering:
begindatum/tijd:1jan/16:00uur
einddatum/tijd:7jan/10:00uur

Als ik dan een reserveering van 7 jan tot 21 jan wil maken kan dat niet omdat de 7 al volgeboekt zit. Ik dacht dat met de tijd te vermelden op te lossen. Of wat zijn jullie ideeën hier over?

begindatum/tijd:1jan/Aankomst
einddatum/tijd:7jan/Vertrek

bovenstaan de kan ook, komt natuurlijk op het zelfde neer

[Janoz]

Over het algemeen is het behoorlijk gebruikelijk dat de ene club 's ochtends de caravan verlaat en dat de volgende club er 's avonds al weer in zit. Op welk moment de wissel plaatsvindt is in principe voor je applicatie net echt van belang. het is vaak gebruikelijk dat je ergens voor 12u uit moet en dat je er pas na 15u in mag. Je reserveringen laat je gewoon overeenkomen met wie er 's avonds in zit. Iemand die op 8 januari vertrekt sla je in de DB op alsof alles tot (dus niet tot en met) 8 januari vrijbezet is.

De tijd zou ik alleen opnemen wanneer je een hotel in de buurt van een rosse buurt hebt waarbij alles per uur verhuurt kan worden.

@hieronder: Inderdaad, typefoutje. Hij zat alleen ergens anders dan dat jij zei .

[ Voor 7% gewijzigd door Janoz op 17-10-2007 16:05 ]

[Verwijderd]

Janoz schreef op woensdag 17 oktober 2007 @ 15:01:
Je reserveringen laat je gewoon overeenkomen met wie er 's avonds in zit. Iemand die op 8 januari vertrekt sla je in de DB op alsof alles tot (dus niet tot en met) 8 januari vrij is.

Ik neem aan dat je bedoelt vanaf ipv. tot

Maar dan zit je in bij reserveringen 6 dagen neer. Op het einde hou je dus 1 dag over. Je boekt, zoals ik van jou begrijp dan vrijdag tot donderdag. (Terwijl hij er is van vrijdag middag tot vrijdag ochtend) De bezoeker zal er niet veel van merken. Maar in een admin gedeelte, waar een overzicht van alles kan komen te staan, geeft dit verwaring, denk ik. Of je moet bij het uitlezen php er 1 dan bij op laten tellen maar dat lijkt mij nu ook niet de meest idiale oplossing...

[DamadmOO]

Nee je zet het er gewoon in als 7 dagen. Alleen zie je de einddatum van een periode als "tot" en niet als "tot en met". Een week is dus van vrijdag tot vrijdag. En niet van vrijdag tot en met vrijdag.

Verder heb je totaal geen tijden nodig. Dat is iets om de behandelingen van een dokter in te plannen maar voor vakantiehuisjes is dat zwaar overbodig. Het kost alleen maar extra tijd (is geld) om te ontwikkelen. Het zal nooit gebruikt worden. En doordat er meer ontwikkeld moet worden is er een grotere kans dat er een bug in komt wat weer tijd (is geld) vraagt om op te lossen. En aangezien de eigenaar van de site waarschijnlijk zo min mogelijk geld wil investeren (en zeker niet wil betalen voor iets wat hij niet gaat gebruiken) zou ik er dus niet eens aan beginnen. Mocht het later toch nodig zijn dat de tijden erin moeten dan kan je dit vrij makkelijk toevoegen zolang je alles maar goed in elkaar zet in eerste instantie.

[TERW_DAN]

Verwijderd schreef op woensdag 17 oktober 2007 @ 15:14:
[...]


Ik neem aan dat je bedoelt vanaf ipv. tot

Maar dan zit je in bij reserveringen 6 dagen neer. Op het einde hou je dus 1 dag over. Je boekt, zoals ik van jou begrijp dan vrijdag tot donderdag. (Terwijl hij er is van vrijdag middag tot vrijdag ochtend) De bezoeker zal er niet veel van merken. Maar in een admin gedeelte, waar een overzicht van alles kan komen te staan, geeft dit verwaring, denk ik. Of je moet bij het uitlezen php er 1 dan bij op laten tellen maar dat lijkt mij nu ook niet de meest idiale oplossing...

Dat hangt van je applicatie af. Bij hotels wordt het voornamelijk als overnachtingen gezien, en een overnachting beslaat 2 dagen (bijv zaterdag op zondag).
Als je je applicatie op die manier inricht kan het prima.
Je boekt de caravan op een vrijdag tot dinsdag. Dat betekent dat je vrijdag, zaterdag, zondag en maandag een overnachting hebt. De overnachting die dan voor dinsdag plaatsvind kan gewoon weer geboekt worden, ook al zijn de gasten pas op dinsdag ochtend eruit ipv maandag om 23:59:59.

[Verwijderd]

Ja oké,

Maar nu dit:

Er staat in de database:

Beschikbaar
begindatum1jan
einddatum21jan

Reservering:
begindatum:1jan
einddatum:7jan

Iemand gaat boeken van 7jan tot 21 jan. PHP gaat aan het zoeken in de database. Hij vindt de datum 7 dan al bij de reserveringen. Dan zal hij toch FALSE terug geven?

[Verwijderd]

Als we even uit gaan van een volledige beschikbaarheid (=camping is altijd open), kan je met één tabel af.
Je reservering tabel zal er ongeveer zo uit zien:

- reserveringsid
- begindatum
- einddatum

- klantid (of naam, of whatever)
- misschien wel standplaatsid ofzo

Je kan dan adhv die datums bekijken of er vrije ruimte is.

[Ruudjah]

DIT BERICHT IS PREVENTIEF VERWIJDERD DOOR DE GEBRUIKER

[ Voor 100% gewijzigd door Ruudjah op 01-12-2009 22:11 ]

[DamadmOO]

Verwijderd schreef op woensdag 17 oktober 2007 @ 15:44:
Iemand gaat boeken van 7jan tot 21 jan. PHP gaat aan het zoeken in de database. Hij vindt de datum 7 dan al bij de reserveringen. Dan zal hij toch FALSE terug geven?

Dat ligt eraan hoe jij je het in je businesslaag afvangt.

En PHP zoekt niet in de database. PHP geeft de opdracht aan MySQL om in de database te zoeken. Je krijgt dus ook geen FALSE of TRUE maar gewoon een resultaat.

[Croga]

Verwijderd schreef op woensdag 17 oktober 2007 @ 15:44:
Er staat in de database:

Beschikbaar
begindatum1jan
einddatum21jan

Dat is al fout. De laatste beschikbare dag is 21 Januari dus de laatste beschikbare nacht is 20 Januari. Aangezien je nachten boekt is de beschikbaarheid dus 1Jan t/m 20Jan

Reservering:
begindatum:1jan
einddatum:7jan

Iemand gaat boeken van 7jan tot 21 jan. PHP gaat aan het zoeken in de database. Hij vindt de datum 7 dan al bij de reserveringen. Dan zal hij toch FALSE terug geven?

Een verblijf van 1Jan tot 7Jan wordt opgeslagen als 1Jan t/m 6Jan aangezien de nacht van 7 Januari niet meer verbleven wordt.

[DamadmOO]

Croga schreef op woensdag 17 oktober 2007 @ 16:01:
[...]

Dat is al fout. De laatste beschikbare dag is 21 Januari dus de laatste beschikbare nacht is 20 Januari. Aangezien je nachten boekt is de beschikbaarheid dus 1Jan t/m 20Jan

[...]

Een verblijf van 1Jan tot 7Jan wordt opgeslagen als 1Jan t/m 6Jan aangezien de nacht van 7 Januari niet meer verbleven wordt.

Sorry hoor maar waar kan jij vinden dat de TS de nachten gaat opslaan? Er zijn meerdere manieren om dit probleem op te lossen en door de manier van het gebruiken van nachten is hier één van. Je kan dus niet zeggen of iets goed of fout is als je niet weet welke manier er gebruikt gaat worden...

[Verwijderd]

Verwijderd schreef op woensdag 17 oktober 2007 @ 15:48:
Als we even uit gaan van een volledige beschikbaarheid (=camping is altijd open), kan je met één tabel af.

Dit is niet de bedoeling. personen die een eigen caravan hebben en daar niet elke week van het jaar gebruik van maken kunnen zelf aangeven welke weken ze de caravan willen verhuuren. (hoeven dus ook niet aangeen gesloten te zijn) Er zijn dus, volgensmij, gewoon twee tabellen nodig.

Ik zal waarschijnlijk volgende week starten met het maken van de site zelf. (Deze week het ontwerp). Ik ga het op applicatieniveu probeeren op te lossen. Als ik er niet uit komt dan horen jullie het wel

Tips blijven alteid welkom

[Janoz]

Sorry hoor maar waar kan jij vinden dat de TS de nachten gaat opslaan?

Dat is nergens te vinden, wat wel te vinden is zijn veel reacties van mensen die dit aanraden en aangeven dat dit een veel werkbaardere vorm is. De TS interpreteerd deze voorstellen niet helemaal jusit dus schrijft Croga dit voorbeeld ietsje duidelijker uit.

[steffex]

Ik heb niet alles gelezen, maar waarom zou je de beschikbaarheid willen opslaan? De beschikbaarheid kun je ook ophalen door te kijken naar de boekingen! Dan heb je meteen 1 plek waar het minder fout kan gaan!

[Janoz]

@stef-o: Beschikbaarheid is niet alleen afhankelijk van de boekingen, maar ook of een caravan überhaupt in die periode verhuurt wordt door de eigenaar.

[Verwijderd]

Croga schreef op woensdag 17 oktober 2007 @ 16:01:
[...]

Dat is al fout. De laatste beschikbare dag is 21 Januari dus de laatste beschikbare nacht is 20 Januari. Aangezien je nachten boekt is de beschikbaarheid dus 1Jan t/m 20Jan

Er worden geen nachten geboekt of aangebonen. Het gaat over weken. Daarom zat ik in mijn eerste post ook met weeknummer te pielen

[DamadmOO]

stef-o schreef op woensdag 17 oktober 2007 @ 16:08:
Ik heb niet alles gelezen, maar waarom zou je de beschikbaarheid willen opslaan? De beschikbaarheid kun je ook ophalen door te kijken naar de boekingen! Dan heb je meteen 1 plek waar het minder fout kan gaan!

Uit de topicstart:
Heeft een willekeurig persoon een stacaravan dan kan hij zich wenden tot de beheerders van de website. Deze kunnen dan 3 foto’s, een omschrijving, een koppeling naar de camping, de beschikbare weken, het maximaal aantal personen en de prijs uploaden.
Dat was de vierde regel of zoiets. Doordat de stacaravans niet altijd beschikbaar zijn zul je de beschikbaarheid dus wel moeten registeren

[elhopo]

Kijk eens of het mogelijk moet zijn om rekening te houden met extra's zoals:
-lakenpakketten
-kinderstoelverhuur
(enz)
prijsstructuren: vroegboekkortingen, 3=2 (3 weken voor de prijs van 2) enz..
tipje : wanneer iemand op een bepaalde plaats wil boeken, maak je op de achtergrond een string aan met Xjes voor de gereserveerde dagen en spaties voor de vrije. Zo kan je makkelijk zien wat er nog vrij is, ook in je code. vb:
januari
xxxxxxx xxxxxxx xxx
zo zie je vrij vlot dat de 1e 7 dagen bezet zijn, de 2e 7 vrij, enz... Prijzen kan je ook zo berekenen, want dat is een lastig iets om te doen, je zit altijd met omslagpunten (en dat is vaak niet precies op een wisseldag) stel: je hebt tarief 1, 2 en 3. Je maakt dan een tariefstring:
111111111112222222333333
je telt het aantal 1en, 2en en 3en voor die periode en vermenigvuldigt die met de bijbehorende per nacht. Zo is het ook makkelijk om de voordeligste nachten weg te geven bij een 3=2 actie.
(en ja, ik heb wel eens iets gedaan met een dergelijke applicatie)
wellicht zijn er wel 100 wegen die naar Rome leiden, maar dit is alvast 1 daarvan...

[Janoz]

Verwijderd schreef op woensdag 17 oktober 2007 @ 16:12:
[...]


Er worden geen nachten geboekt of aangebonen. Het gaat over weken. Daarom zat ik in mijn eerste post ook met weeknummer te pielen

We hadden eht al niet meer over weken toen je zelf naar voren kwam met de (toekomstige) mogelijkheid om ook lange weekenden te kunnen boeken. Zoek maar eens op 'hemelvaart' in dit topic.

[Verwijderd]

Janoz schreef op woensdag 17 oktober 2007 @ 16:19:
[...]

We hadden het al niet meer over weken toen je zelf naar voren kwam met de (toekomstige) mogelijkheid om ook lange weekenden te kunnen boeken. Zoek maar eens op 'hemelvaart' in dit topic.

Als er een weekend aan gebonden wordt, wat inderdaad in de toekomst tot een mogenlijkheid behoord, dan is de week er voor of er na niet als week meer te verkopen. het zijn halve stukken. met midweeken wordt niet gewerkt.

[Verwijderd]

elhopo schreef op woensdag 17 oktober 2007 @ 16:18:
Kijk eens of het mogelijk moet zijn om rekening te houden met extra's zoals:
-lakenpakketten
-kinderstoelverhuur
(enz)
prijsstructuren: vroegboekkortingen, 3=2 (3 weken voor de prijs van 2) enz..
tipje : wanneer iemand op een bepaalde plaats wil boeken, maak je op de achtergrond een string aan met Xjes voor de gereserveerde dagen en spaties voor de vrije. Zo kan je makkelijk zien wat er nog vrij is, ook in je code. vb:
januari
xxxxxxx xxxxxxx xxx
zo zie je vrij vlot dat de 1e 7 dagen bezet zijn, de 2e 7 vrij, enz... Prijzen kan je ook zo berekenen, want dat is een lastig iets om te doen, je zit altijd met omslagpunten (en dat is vaak niet precies op een wisseldag) stel: je hebt tarief 1, 2 en 3. Je maakt dan een tariefstring:
111111111112222222333333
je telt het aantal 1en, 2en en 3en voor die periode en vermenigvuldigt die met de bijbehorende per nacht. Zo is het ook makkelijk om de voordeligste nachten weg te geven bij een 3=2 actie.
(en ja, ik heb wel eens iets gedaan met een dergelijke applicatie)
wellicht zijn er wel 100 wegen die naar Rome leiden, maar dit is alvast 1 daarvan...

Jij zecht dus niet met datums werken maar met X-jes. Dit lijkt mij wel een goede oplossing, Alleen krijg je dan voor elke caravan 12 rijen, want elke maand heeft een serie, of hoe moet ik me dat voorstellen?

[elhopo]

Verwijderd schreef op woensdag 17 oktober 2007 @ 16:32:
[...]


Jij zecht dus niet met datums werken maar met X-jes. Dit lijkt mij wel een goede oplossing, Alleen krijg je dan voor elke caravan 12 rijen, want elke maand heeft een serie, of hoe moet ik me dat voorstellen?

Wat een mogelijkheid is is dat je aan de hand v.d. bekende gegevens uit de database, dus wanneer is een caravan beschikbaar voor verhuur, een string van 365 karakters maakt. Wanneer de caravan beschikbaar is, zet je een spatie (of een O of whatever) in de string, wanneer deze niet beschikbaar is een X (oid). Vervolgens ga je met deze string langs de reserveringen, op een zelfde manier. Je kan dan ook een X plaatsen, of een andere letter om verschil te hebben tussen niet beschikbaar en gereserveerd. in de database staan weldegelijk datums.

Met deze string kan je bijv later ook een visueel overzichtje genereren waar je bijv bepaalde kleuren gebruikt voor vrij (groen?) gereserveerd (rood?) en niet beschikbaar (grijs?) zodat de gebruiker snel kan zien wanneer er nog plek is.

Deze string sla je overigens (denk ik?) niet op, je kan hem nl. iedere keer opnieuw genereren. Wellicht is het wel handig om 'm te buferen ivm performance...

enige nadeel: hoe doe je dat met een jaarwisseling... (maar wie gaat er op 1 januari op een camping zitten......). Alternatief: reken vanaf een opgegeven datum 2 weken terug en 6 weken vooruit, en bouw hier een string mee op...

[Verwijderd]

Heb je toevalig uit je eigen applicatie een voorbeeld hou jij die string gemaakt heb?

Op deze manier heb ik nog nooit gewerkt nl. Het is dus allemaal 'van hooren zeggen'

[DamadmOO]

Ik zou dus echt nooit met zo'n string gaan werken. Het zal misschien wel werken maar het is echt performance killing. En waarom zou je zo'n, veel moelijker te realiseren, work-around maken terwijl dat dus totaal niet nodig is. Lees alles in het topic nog eens rustig door. Maak je database en zet er wat testdata in en kijk dan eens hoe makkelijk het eigenlijk wel niet is.

Kom je er dan alsnog niet uit dan kan je gewoon je databaseontwerp posten en hetgeen wat je geprobeerd hebt (en dan vooral het laatste).

[Croga]

Verwijderd schreef op woensdag 17 oktober 2007 @ 16:12:
Er worden geen nachten geboekt of aangebonen. Het gaat over weken. Daarom zat ik in mijn eerste post ook met weeknummer te pielen

Als je persé alleen met weken wilt werken is het nog veel makkelijker... dan hoef je alleen de weeknummers maar op te slaan als beschikbaarheid en heb je de tijd al helemaal niet meer nodig.

Als je met dagen wilt gaan werken (of eigenlijk met nachten, zoals de hele branche doet) kun je net zo makkelijk weken verhuren terwijl je toch de flexibiliteit houd.

Met die strings zou ik al helemaal nooit gaan werken. Ten eerste kost het veel meer ontwikkeltijd, ten tweede ben je alle overzichtelijkheid (en dus onderhoudbaarheid) kwijt. Ten derde hebben wij mensen enkele eeuwen geleden al een systeem bedacht met maanden en dagnummers wat universeel geaccepteerd is (in ieder geval een stuk breder geaccepteerd dan "Ik heb X nummer 254 tot en met X nummer 260 een caravan geboekt")

Er wordt hier op een aantal plaatsen en nieuw wiel uitgevonden terwijl er al wielen beschikbaar zijn die zich al jarenlang bewezen hebben.....

[Nick_S]

Verwijderd schreef op woensdag 17 oktober 2007 @ 12:04:
Begrijp ik het goed dat jullie dit zeggen:

Camping	Caravan	Klant	Reservering	beschikbaar	Foto
Camping_id Camping_plaats Camping_omschijving Camping_URL1 Camping_URL2	Caravan_id Camping_id Max_personen Caravan_omschijving Caravan_prijs	Klant_id Naam Adres Postcode Plaats Email	Caravan_id Klant_id Begintijd/datum Eindtijd/datum	Caravan_id Begintijd/datum Eindtijd/datum	Foto_id Camping_id Caravan_id Foto_URL Foto_width Foto_height

Als ik het zo oplost dan zie ik een volgend probleem. Als een caravan 5 weken beschikbaar is, en week 2 en 3 worden geboekt. Dan doet hij het net meer zoals hier boven staat. Of je moet voor elke dag een record maken... × aantal caravan's. Dat betekend een heleboel data. Is er geen efficentere manier?

Klein puntje, waarom sla je bij een foto een camping ID op? Dit is in principe overbodige data, en kan nog voor 'problemen' zorgen. (Als een caravan van de ene naar de andere camping verhuist en je vergeet om de foto's ook te updaten, bv.)

Oh, en moeten er van een bepaalde caravan ook geen eigenaarsgegevens opgeslagen worden? Zo ja, moet 1 eigenaar meerdere caravan (over meerdere campings) kunnen hebben?

[ Voor 5% gewijzigd door Nick_S op 18-10-2007 00:02 ]

[elhopo]

Lezen is ook een vak, he? ik meld duidelijk dat je de gegevens gewoon als data opslaat, en dat je hier in je source een string van maakt, die veel makkelijker te manipuleren en te parsen is dan een collectie van datums.
Het is geen work around, het is hoe de "grote" jongens het doen (ik heb wel eens meegewerkt aan een dergelijk reserveringsprogramma voor een grote verhuurder van ingerichte stacaravans en tenten).

Met die string kan je vervolgens wat makkelijker kijken waar plaats is, enz. Reserveringen sla je vervolgens weer als datum op. Wij mensen snappen datums als maanden en dagen heel goed, alleen computers kunnen dit vrij lastig interpreteren, zeker als dit een setje records uit een database is (met een begin- en einddatum). Vandaar mijn voorstel, maar zoals ik al zei: er zijn wellicht wel 100 wegen die naar rome leiden, het is aan de TS om zijn eigen weg hierin te kiezen.

[Verwijderd]

Nick_S schreef op donderdag 18 oktober 2007 @ 00:01:
[...]

Klein puntje, waarom sla je bij een foto een camping ID op? Dit is in principe overbodige data, en kan nog voor 'problemen' zorgen. (Als een caravan van de ene naar de andere camping verhuist en je vergeet om de foto's ook te updaten, bv.)

Oh, en moeten er van een bepaalde caravan ook geen eigenaarsgegevens opgeslagen worden? Zo ja, moet 1 eigenaar meerdere caravan (over meerdere campings) kunnen hebben?

Bij foto staat een camping_id en een caravan_id om dat er fotos voor en de caravans komen en voor de campings komt er ook een verhaal met foto's van de camping.

Eigenaars gegevens van de caravan is een goede! Hier was ik eerlijkgezecht helemaal overheen gegaan! En ik denk dat 1 eigenaar inderdaad meer caravans kan hebben, als het een keer voor komt, dat is het er allemaal op voor berijd.

Camping	Caravan	Eigenaar	Klant	Reservering
Camping_id Camping_plaats Camping_omschijving Camping_URL1 Camping_URL2	Caravan_id Camping_id Eigenaar_id Max_personen Caravan_omschijving Caravan_prijs	eigenaar_id Naam Adres Postcode Plaats Email Rekeningnummer plaats_rekeningnummer	Klant_id Naam Adres Postcode Plaats Email	Caravan_id Klant_id Begintijd/datum Eindtijd/datum

beschikbaar	Foto
Caravan_id Begintijd/datum Eindtijd/datum	Foto_id Camping_id Caravan_id Foto_URL Foto_width Foto_height

bedankt voor de tip!

En nog over die strings... Ik heb zo nog nooit gewerkt, heeft iemand een voorbeeld hoe ik het toemoet passen? (Ik wil me goed laten informeeren naar de mogenlijkheden en een combinatie van de beste en handigste oplossing kiezen).

[ Voor 28% gewijzigd door Verwijderd op 18-10-2007 09:24 . Reden: DB tabel aangepast ]

[Nic]

Om het nog even ingewikkelder (of eigenlijk, eenvoudiger) te maken:

- Ik zou zelf de tabel met klanten en eigenaars samenvoegen naar een tabel 'personen'. Uit de tabel met caravans en de tabel met reserveringen blijkt vanzelf wel of iemand een klant is of een eigenaar, en bovendien hoeven de gegevens van de eigenaar van een caravan niet opnieuw ingegeven te worden als hij eens een caravan op een andere camping huurt.

- Idem met tabel beschikbaarheid, die kan vervallen: Je maakt een speciale klant met de naam 'niet beschikbaar', die in de tabel met reserveringen ervoor zorgt dat de caravan voor die periode 'gereserveerd' is. En als je de tabel met klanten en eigenaars hebt samengevoegd, kun je ook de eigenaar zijn eigen caravan laten reserveren.

- Moet er ook management-informatie uit de tabellen gehaald worden? In dat geval zou ik de caravan zelf ook een begin/einddatum geven, zodat de oude reserveringen bewaard kunnen blijven als een caravan ooit verdwijnt, terwijl de caravan niet meer boekbaar is.

- ik zou niet met strings gaan werken om beschikbaarheid te bekijken in je code. Je kunt eenvoudig met je sql instructie kijken of een periode nog beschikbaar is:

als je wilt checken naar beschikbaarheid in de periode datum1 t/m datum2:
caravan is nog beschikbaar if not exists(select * from reservering where (begindatum<datum1 and einddatum>datum1) or (begindatum<datum2 and einddatum>datum2) or (begindatum>datum1 and einddatum<datum2))

uitleg:
3 situaties worden gechecked:
- op datum1 loopt er al een reservering
- op datum2 loopt er al een reservering
- er valt een bestaande reservering volledig binnen de gewenste data

Op die manier kun je de caravans zelfs per uur gaan reserveren als je zou willen.

[ Voor 3% gewijzigd door Nic op 18-10-2007 10:42 ]

[Verwijderd]

Bedankt voor je bericht! Ik krijg steeds meer het gevoel dat we er dichter bij komen!

Ik zou dan dit krijgen:

Camping	Caravan	Personen	Reservering
Camping_id Camping_plaats Camping_omschijving Camping_URL1 Camping_URL2	Caravan_id Camping_id Eigenaar_id Max_personen Caravan_omschijving Caravan_prijs actief (0=nee, 1=ja)	personen_id Naam Adres Postcode Plaats Email Rekeningnummer plaats_rekeningnummer Categorie (0=eigenaar, 1=huurder)	Caravan_id Klant_id Begintijd/datum Eindtijd/datum

beschikbaar	Foto
Caravan_id Begintijd/datum Eindtijd/datum	Foto_id Camping_id Caravan_id Foto_URL Foto_width Foto_height

dsltv schreef op donderdag 18 oktober 2007 @ 10:37:
- Idem met tabel beschikbaarheid, die kan vervallen: Je maakt een speciale klant met de naam 'niet beschikbaar', die in de tabel met reserveringen ervoor zorgt dat de caravan voor die periode 'gereserveerd' is. En als je de tabel met klanten en eigenaars hebt samengevoegd, kun je ook de eigenaar zijn eigen caravan laten reserveren.

Dit begrijp ik niet helemaal. Als ik één klant maakt met de naam 'niet beschikbaar'. Deze 'boekt' een reserveering. Dit betekend dus als de eigenaar een caravan op gaat geven hij door geeft wanner de caracan NIET beschikbaar is. Is het niet logischer dat de eigenaar opgeeft wanneer hij WEL beschikbaar is? of licht dat aan mij?

dsltv schreef op donderdag 18 oktober 2007 @ 10:37:
- Moet er ook management-informatie uit de tabellen gehaald worden? In dat geval zou ik de caravan zelf ook een begin/einddatum geven, zodat de oude reserveringen bewaard kunnen blijven als een caravan ooit verdwijnt, terwijl de caravan niet meer boekbaar is.

Dit heb ik opgelost door in de tabel caranans actief/inactief neer te zetten. zo zijn alle gegevens alteid beschikbaar. Of ben ik nu raar aan het doen? (veel data verwacht ik niet, meer dan 300/400 carvans wordt nooit gehaald denk ik, dus hoeveelheid data valt ook wel mee)

Je SQL query is duidelijk!

[Janoz]

Verwijderd schreef op donderdag 18 oktober 2007 @ 11:25:
Dit begrijp ik niet helemaal. Als ik één klant maakt met de naam 'niet beschikbaar'. Deze 'boekt' een reserveering. Dit betekend dus als de eigenaar een caravan op gaat geven hij door geeft wanner de caracan NIET beschikbaar is. Is het niet logischer dat de eigenaar opgeeft wanneer hij WEL beschikbaar is? of licht dat aan mij?

Het is al meerdere keren naar voren gekomen, maar ik herhaal het nogmaals. De manier waarop de data in de database staat is de manier waarop hier handig mee te wekren is, maar hoeft helemaal niet 1 op 1 overeen te komen met de presentatie aan de voorkant. Je kunt in je programma toch makkelijk zelf die omslag maken?

Tot slot wil ik je vragen niet zo te hameren op een code voorbeeld van die strings. De werking is redelijk duidelijk uitgelegd. Kun je deze uitleg niet zelf omzetten in een stuk code, dan moet je het ook maar beter niet gebruiken.

[Nick_S]

Verwijderd schreef op donderdag 18 oktober 2007 @ 11:25:
Dit heb ik opgelost door in de tabel caranans actief/inactief neer te zetten. zo zijn alle gegevens alteid beschikbaar. Of ben ik nu raar aan het doen? (veel data verwacht ik niet, meer dan 300/400 carvans wordt nooit gehaald denk ik, dus hoeveelheid data valt ook wel mee)

Door dit met een boolean op te lossen, verlies je historische data. Zoals bijvoorbeeld, is deze caravan populair? (Als in, vaak volgeboekt, als je niet bijhoudt van wanneer tot wanneer een caravan actief is geweest, is dit dus niet meer terug te halen) Het ligt er natuurlijk weer aan, hoe uitgebreid je het wilt hebben, dit is just a sidenote.

[Verwijderd]

Zulke gegevend zijn nodig. Het moet simpel zijn. Dat wil zeggen, het moet functioneeren zonder te veel extra's.
maar bedankt voor het mee denken!

[Nick_S]

Verwijderd schreef op donderdag 18 oktober 2007 @ 12:09:
Zulke gegevend zijn nodig.

Door het dan met een 'aktief' boolean op te lossen, mis je de historische data. Je kan nooit meer terug kijken van wanneer tot wanneer een caravan 'aktief' is geweest.

Het moet simpel zijn.

Je datamodel kan beter te uitgebreid dan te simpel zijn. In je eerste versie, hoef je niet alles te gebruiken, natuurlijk.

[Verwijderd]

Verwijderd schreef op donderdag 18 oktober 2007 @ 12:09:
Zulke gegevend zijn nodig.

Nick_S schreef op donderdag 18 oktober 2007 @ 13:01:
Door het dan met een 'aktief' boolean op te lossen, mis je de historische data. Je kan nooit meer terug kijken van wanneer tot wanneer een caravan 'aktief' is geweest.

Sorry, een foutje. er had moeten staan 'Zulke gegevens zijn NIET nodig'

[Nick_S]

Verwijderd schreef op donderdag 18 oktober 2007 @ 13:28:
[...]


[...]


Sorry, een foutje. er had moeten staan 'Zulke gegevens zijn NIET nodig'

Scheelt maar een paar letters.

[Verwijderd]

Ja idd, 'Gewoon' een woord vergeten te typen

[Croga]

elhopo schreef op donderdag 18 oktober 2007 @ 08:32:
ik meld duidelijk dat je de gegevens gewoon als data opslaat, en dat je hier in je source een string van maakt, die veel makkelijker te manipuleren en te parsen is dan een collectie van datums.
<knip>
Wij mensen snappen datums als maanden en dagen heel goed, alleen computers kunnen dit vrij lastig interpreteren, zeker als dit een setje records uit een database is (met een begin- en einddatum).

urrrr.... computers vinden een datum lastig? Dat is de eerste keer dat ik dat hoor.... Zelfs in SQL kun je heel makkelijk met datum velden werken en ook programeertalen hebben er in het geheel geen moeite mee. Een string die dagen moet voorstellen is heel wat meer code voor nodig om te manipuleren dan simpelweg een datum of datumreeks.