Tarief berekenen

NoellaG zei:

Dag Astrid, ik vind het tof dat je als beginneling zoiets in elkaar kunt boksen.

Klik om te vergroten...

Dank je wel

NoellaG zei:

Probeer echter niet in te valkuil te vallen dat je veel tijd steekt in wat niet je core business is. Er bestaan reeds veel professionele boekingspakketten voor B&B's en hotels.

Klik om te vergroten...

Klopt maar wij zijn net begonnen en alles moet helaas nog lowbudget. Dus roeien met de riemen die je hebt (zelf kunt maken)...

NoellaG zei:

Ook webtoepassingen die je eventueel vanop je smartphone kan invullen als je dat zou willen. Een klassiek pakket bv. [url]https://roomraccoon.com/boekingssoftware/ . [/URL] , https://www.123boeken.nl/complete-website/

Klik om te vergroten...

Geloof het of niet...we zitten in één van de grootste steden maar de gemeente (onze verhuurder) heeft niet gezorgd (en zal ook niet zorgen) voor internet. Dus alle internetverbinding komt uit mijn mobiele hotspot. Niet echt betrouwbaar om dan een boekingssysteem online te houden.

Sorry, ik wist niet wat ik mij hier op de hals had gehaald. Ik dacht met een kleine aanpassing weer verder te kunnen. Anders hou ik het zoals het is of probeer het iets aan te passen. In het ergste geval begin ik ieder jaar met een lege database...

"Gaat het niet zoals het moet, dan moet het maar zoals het gaat"

Vriendelijke groetjes,

Astrid

OctaFish zei:

Dat riekt een beetje naar pamperen . En je weet: zachte heelmeesters maken smerige wondeen . Maar ik snap dat je trots bent op je db. Desalniettemin: als hij niet goed is, zal toch iemand dat tegen je moeten zeggen .

Klik om te vergroten...

Tuurlijk, je hebt helemaal gelijk...

OctaFish zei:

Om te beginnen: de grootte kan dus echt wel omlaag, kijk maar naar de bijlage. Ik zal vanmiddag, als ik meer tijd heb, wel wat meer tips geven.

Klik om te vergroten...

Zolang het maar niet ingewikkeld is... zie ook mijn tekst bij NoellaG

;-) Vriendelijke groetjes,

Astrid

Wat mij opvalt, is dat de db ongelooflijk traag is, ondanks dat er maar een paar records inzitten. Dat belooft niet veel goeds voor het vervolg. Daarnaast ben je (wat mij betreft) in een aantal valkuilen gestort die Microsoft de laatste jaren heeft ingebouwd, en die naar mijn bescheiden mening niet in een database thuishoren, zoals berekende velden (nooit doen), keuzelijsten in tabellen (op basis van een tabel) (ook nooit doen) en binnen de db opgeslagen objecten (vandaar de idiote grootte; ook nooit doen).

Maar de grootste zorg baart dus de snelheid. Een db van dit kaliber zou over het scherm moeten vliegen .

aromijn99 zei:

Maar alsjeblieft steek geen tijd in het totaal verbouwen van mijn database. Meer dan dit is voor mij toch niet haalbaar. Veel meer tijd kan ik er ook niet insteken

Klik om te vergroten...

De grap van HelpMij is nu juist dat er zat mensen zijn die het leuk vinden om dit soort databases te verbeteren . Het hoeft ook helemaal niet zoveel tijd te kosten als je denkt. Jij mist, als beginner, de noodzakelijke kennis om een db goed in te richten. Dat neemt niemand je uiteraard kwalijk, maar het is wel bar vervelend in dit geval.

Als ik een brief krijg van de gemeente die is getypt door iemand met twee linkerhanden die totaal geen verstand heeft van tekstverwerken, dan zie ik dat absoluut niet terug (normaal gesproken) in de brief die ik in mijn handen heb. Zolang de tekst er goed op staat, is de wijze waarop dat is gebeurd, totaal niet relevant. Bij een database werkt dat helaas niet zo; als je een slechte database ontwerpt, dan heb je daar gelijk stevig last van. Databases maken is dan ook gewoon een vak, en als je dat niet hebt geleerd, dan is het ongelooflijk lastig om een goede database te maken. Microsoft leeft in de foutieve veronderstelling dat ze het proces zodanig kunnen versimpelen dat iedereen het kan. Dat werkt prima voor Word en Excel, maar dus niet voor Access.

Je bent een heel eind gekomen zonder basiskennis, maar er zitten dus gewoon fouten in je ontwerp, en die moeten er ooit een keer uit. En wat mij betreft: zo snel mogelijk .

Ik heb in je voorbeeldje wat (in mijn ogen noodzakelijke) aanpassingen gemaakt, en een query die de tarieven berekent met een cartesisch product. Kijk maar eens naar de query qAankomstVoertuig.

druk druk druk

Beste Octa,

Sorry dat ik al twee weken niets meer heb laten weten. Het is nogal druk geweest dus had ik er weinig tijd voor. Ik zal zo spoedig mogelijk naar je oplossing kijken die je gemaakt hebt.
Ik waardeer het in ieder geval al heel erg dat je er tijd in hebt gestoken.:thumb:
En ja...traag is ie zeker. Kun je voorstellen hoe die nu gaat, nu die tabel aankomst-voertuig bijna 7000 records heeft

Zodra ik binnenkort weer wat tijd heb ga ik eens goed kijken naar je bevindingen.
Nog ff geduld dus alsjeblieft...

Groetjes, Astrid

aromijn99 zei:

En ja...traag is ie zeker. Kun je voorstellen hoe die nu gaat, nu die tabel aankomst-voertuig bijna 7000 records heeft

Klik om te vergroten...

En dat hoeft dus niet, zeker niet met deze aantallen .

Hoi OctaFish,

Ik ben druk bezig geweest om te begrijpen wat een cartesisch product is.
Dat heb ik in je database gezien via tabel Tarieven en qAankomstVoertuig.

Omdat je natuurlijk niet weet hoe wij onze tarieven berekenen heb ik wat moeten aanpassen:
Men betaalt namelijk niet voor het aantal dagen maar voor het aantal nachten. Dat betekent dat je voor een aankomst op 3-1 en bij een vertrek op 10-1 geen 8 dagen (8xtarief) maar 7 nachten (7xtarief) betaalt. De tabel Tarieven heb ik daarom aangepast zodat de dagen overlappen:
De 1e datumID was tot 6-1.
De 2e datumID is vanaf 7-1.
Dan doet 6-1 dus niet mee. Dus 1e datumID gewijzigd in 7-1.

In de qAankomstVoertuig dan ook bij kolom Tarieven: +1 verwijdert.

Daarbij zag ik dat bij Tabel Tarieven het seizoen vermeld werd ipv het tarief. Omdat ik straks toch moet gaan rekenen heb ik gemeend dit te wijzigen in een kolom seizoen en tarief. Dit omdat de seizoenen in de jaren natuurlijk verhoogd worden in tarief.

Alleen heb ik ook jouw aanwijzingen gezien: berekende velden (nooit doen)

Vraag ik mij nu wel af: waar dan wel? In mijn inschrijfformulier (waarin de klant bij inschrijving meeleest dus daar moeten wel de bedragen te zien zijn) of erachter in een query? Of weer ergens anders?

Ook schreef je dit: keuzelijsten in tabellen (op basis van een tabel) (ook nooit doen)
Waar zou je het dan doen?

Ik heb ook gemerkt dat er een extra tabel gemaakt is voor Afgenomen Producten, maar zonder product 1, de plaats (tarief afhankelijk van het seizoen). Maar die wordt natuurlijk berekend via qAankomstVoertuig..toch?
Nu moet ik uitzoeken hoe ik dat dus doe met deze tabel, wat je daar voor bedacht heb. Voor mij natuurlijk weer nieuw. Voor jou misschien een eitje maar heel veel breinbrekers voor mij.

De voertuigen in jouw database staan nu niet in een aparte tabel. Volgens mij moet dit wel. Zo hoef je bij terugkerende klanten niet steeds de voertuiggegevens op te geven. En op één inschrijfformulier kan ik zo meerdere campers opgeven (als een gezelschap met 3 campers komen). Ieder met eigen producten en op een eigen plaats. Maar gewoon op 1 inschrijving (1 factuur). Ook de gegevens van terugkerende klanten hoeven dan niet steeds te worden vermeld. Alleen het voertuig Id.

Mijn tabel Aankomst heb je tReserveringen genoemd. Vind ik niet zo handig omdat we meestal geen reserveringen hebben maar gewoon gasten die aankomen. Soms reserveren ze wel maar komen ze gewoon ook in deze tabel met situatie gereserveerd ipv gearriveerd.

Die tabel Tproducten ziet er beter uit dan mijn oude versie. Kennelijk is het beter de afbeeldingen elders op te slaan. Moet ik nog wel ff uitproberen hoe dat gaat.

Ik ga weer verder worstelen, het moet er natuurlijk toch ongeveer gaan uitzien zoals het inschrijfformulier zoals het was voor de klant. Alleen met een betere opbouw erachter. Ik zal wel geholpen zijn antwoorden op bovenstaande vragen, als je er nog zin in hebt…

Alvast weer heel erg bedankt.

Ik zal er eens naar kijken dit weekend. Naamgeving van tabellen is natuurlijk totaal irrelevant voor een database; een naam heeft geen enkele invloed op de werking van een db. Mij leek tReserveringen een logische benaming, omdat ik er vanuit ging dat gasten van te voren aangeven wanneer ze komen. En niet op de bonnefooi. In het eerste geval spreek je wel degelijk van een reservering; als mensen dat nooit doen, en je dus nooit weet wie wanneer komt, dan is een tabelnaam als tVerblijf nog altijd beter als tAankomstVoertuig. De aankomst is namelijk een eenmalige handelig, en zegt niks over de verblijfsduur. En uiteindelijk is dát hetgene je registreert, niet hoe laat ze aankomen.