juiste mysql query aantal beschikbare timeslots te achterhalen
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
- Ik maak gebruik van meerdere tabellen (elke dag heeft een nieuw tabel
NOT DONE....
- Velden als: boek_her1, boek_her2, etc.
Tijdvak1, tijdvak2, tijdvak3
NOT DONE
Terug naar de tekentafel....
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
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.
Mijn advies: Gewoon normaliseren..
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.
http://dev.mysql.com/tech-resources/articles/mysql-storedproc.html