Hallo allemaal, ik zit met een klein probleem waar ik zelf niet uitkom en graag de hulp wil inschakelen van de gemeenschap. Ik wil voor mijn online booking systeem kunnen achterhalen wat de aantal beschikbare tijdslots zijn over meerdere dezelfde boeken (maar met een andere boeknummer, e.g. van het boek hersenschimmen zijn 4 stuks, aangeduid met boek_her1, boek_her2, boek_her3 en boek_her4. Ik maak gebruik van meerdere tabellen (elke dag heeft een nieuw tabel). Voor mijn systeem wil ik op voorhand kunnen uitrekenen wat de langste periode is dat het boek uitgeleend kan worden. Dit moeten aaneengesloten uren zijn, beginnende met tijdslot 1 van tabel 1 (elke dag heeft 8 tijdslots van 1 uur). Ik ben momenteel met diverse php codes bezig om per dag, per boek, per tijdslot dit uit te rekenen, maar er is vast een veel simpelere manier (en vooral meer efficientere manier om dit te bewerkstelligen dmv een mysql query
Voorbeeld 3 dagen
Tabel naam: dag1, etc.
Boeknummer: boek_her1, boek_her2, etc.
Tijdvak1, tijdvak2, tijdvak3, etc.
Onder de kolommen tijdvak% komt te staan of deze reeds uitgegeven is.
Ik ben dus geïnteresseerd hoe een mysql query gemaakt kan worden om de aaneengeloten vrije tijdvakken van alle boeken uit te rekenen uitgesmeerd over alle 3 de tabellen. E.g. boek_her1 = 0 (omdat deze niet vrij was tijens tijdvak 1 van tabel: dag 1, boek_her2 = 24 (beschikbaar over complete periode van de 3 dagen... boek_her3 = 11 (boek 3 was al bezet de volgende dag tijdvak 4 etc.
Ik hoop dat iemand mij hierin weet te helpen. Ik hoor alle tips graag. Bedankt,
Gerben, uit Leersum
Had wel redenen om aparte tabellen te gebruiken... mnarjah. Hoop dat iemand toch nog een antwoord had omtrent de query... toch bedankt voor je antwoord aar.
je ziet vaak dat het gebruik van losse tabellen, of genummerde kolommen heel handig is.
maar dan wel alléén voor 1 situatie. Zodra je iets anders wilt, zoals wat je hierboven schetst, dan worden je query's onoverzichtelijk of zelfs onmogelijk.
En als je dan al tot een oplossing komt, loop je het risico dat een kleine aanpassing (niet 8 maar 9 tijdslots, of de tijdslots gaan naar 30 minuten per stuk) tot gevolg heeft dat al je query's opnieuw moeten.
Bedenk een algemeen datamodel, zonder direct na te denken over hoe je in 1 van de gevallen je data op het scherm wilt zetten.
Genummerde kolommen zijn doorgaans een mooie indicatie dat je niet goed bezig bent
Beste ivo, bedankt voor je uitgebreide response... ik heb echt goede reden om aparte tabellen te gebruiken. Maarja, ik begrijp (ook vanwege de response van aar) dat het niet alledaags is. Toch wil ik dit zo doen omdat het maar een gedeelte is van de database structuur en opzet wat je nu ziet. Sorry wil niet eigenwijs zijn, maar is er echt geen oplossing voor de query beschreven zoals ik het had beschreven?
Heel erg bedankt in ieder geval voor het antwoorden,
Groet, Gerben
Wat betreft je database structuur snap ik helemaal niets van. Iets te vaag voor mij. Maar je zou dit eventueel met een stored procedure kunnen afvangen. In deze procedure, kun je bijvoorbeeld SHOW TABLES LIKE .. doen en daar weer verder op anticiperen en uiteindelijk een resultset terug geven.
Met mysqli kun je de procedure aanroepen met CALL naamprocedure en krijg je een of meerdere resultsets terug die je in PHP kan gebruiken.
Echter zou ik eerder in gaan op advies van Aar, om te normaliseren, want als je op deze manier te werk gaat snap je het niet of ben je te eigenwijs (niet persoonlijk bedoelt). Beweren dat er echt geen andere oplossing is, ben ik niet echt van overtuigd, er zijn heel veel (goede) wegen naar rome in ontwikkelland. Hier zou ik niet verder op borduren.
Traag niet perse, denk het niet zelfs. Altijd niet significant heb zelf zulke methoden ook weleens toegepast. Het probleem is dat je dirty fix op dirty fix gaat toepassen en uiteindelijk zit je vast met je code en uiteindelijk ook project.
Ik zou bijvoorbeeld de fix met de stored procedure alleen toepassen als dit een fix/oplossing is in een oude release van je programma en je intussen al bezig bent met een nieuwe versie met een betere database bijvoorbeeld.
Beste aar wederom thx voor je antwoord en @ kees: thx voor de tips, ga er naar kijken. Ga ook me verdiepen op normaliseer gebeuren. Mocht meer mensen tips hebben hoor ik het alsnog heel graag.
