Ik heb een systeem waarin mijn opdrachten worden bijgehouden ik wil dit gaan uitbreiden met een inventaris systeem, waarbij men tevens kan zien of alle items nog op voorraad zijn, maar ik ben bang dat het syteem heel traag wordt.
Ik zal prberen uit te leggen hoe ik het nu heb opgezet.
Ik heb de volgende tabellen
Opdrachten met daarin begin en einddatum van boeking producten met hierin de inventaris opdrachten-producten met hierin id van de opdracht, id van het product en het aantal dat nodig is.
Nu wil ik bij het overzicht van de boeking checken of de voorraard klopt.
Maar dat zou betekenen dat de website bij elke opdracht voor elke dag in de boeking het hele tabel van boekingen-producten, moet doorlezen en moeten uitrekenen of de voorraad klopt.
Sommige opdrachten duren 3 weken, die tussen de 4 tot 40 producten bevatten.
Maar nu dacht ik om per dag elk prouct dat voor deze opdracht nodig is op te halen en vervolgens met te checken of deze producten nogmaals in de de tabel opdrachten-producten voortkomen om vervolgens te kijken of deze gebruikt worden bij een boeking waarbij de datum overeen komt.
Maar als je bedenkt dat hij dit bij bepaalde opdrachten 840 keer moet doen (21 dagen x 40 producten)
Terwijl de tabel opdrachten-producten uit duizenden regels bestaat (200 opdrachten per jaar met gemiddeld 20 producten)
Zou dat betekenen dat hij bij een grote opdracht van 21 dagen en 40 producten bijna 3,5 miljoen handelingen moet doen.
En dan ben ik er nu vanuit gegaan dat er maar 1 medewerker per moment de database raadpleegd.
Gaat mijn website dit aan kunnen of gaat dit mis?
Misschien benader ik dit helemaal verkeerd en zou dit veel makkelijker kunnen? Alle feedback is welkom.
Worden de producten gebruikt bij een opdracht en gaan ze daarna terug het magazijn in? Of worden de producten verbruikt bij een opdracht en moeten ze daardoor opnieuw worden ingekocht?
Wat is verder precies het doel van je systeem? Het hebben van een inventaris is namelijk geen doel. Je wilt daarover iets weten of daarmee iets kunnen doen: wat is dat precies?
De producten tabel klinkt meer als een tabel met resources? Zoals apparatuur/vergaderruimtes/personeel/bedrijfswagens/laptops etc? Dit zijn alle "resources" die op elk moment maar door één proces (opdracht) geclaimd kunnen worden?
Je zou wellicht een (redundant) veld op kunnen slaan bij de items van de resources die op dat moment in gebruik (zouden moeten) zijn? "in_gebruik" ofzo (waarde 0=in magazijn/beschikbaar, 1=in gebruik). En als dat ding weer ingeleverd wordt dan zet je de waarde hiervan weer op 0?
Dan kun je makkelijk de vraag beantwoorden hoeveel items je op voorraad zou moeten hebben:
voorraad van itemtype X = totaal aantal items van type X - aantal items van type X die in_gebruik zijn
Je zou zelfs (nog) een (redundant) veld op kunnen slaan bij de items die aangeeft bij welke opdracht het item op dat moment wordt gebruikt. Dit veld kan mogelijk ook ter vervanging dienen van "in_gebruik". Is het opdracht id NULL, dan is het item niet in gebruik.
Oftewel, sla ergens wat uitgerekende informatie dubbel (redundant) op.
Het gaat om de verhuur van producten, wij hebben bijvoorbeeld 150 podiumdelen.
Waarbij bij de ene opdracht we er 20 inzetten en bij de andere 31.
De producten komen na een bepaalde tijd weer terug.
Het doel van het systeem is constant kunnen zien of er nog producten aanwezig zijn om te verhuren.
Op dit moment bestaat de inventaris uit meer dan 500 verschillende producten.
@ Thomas, Ik negeer je niet, maar probeer even te begrijpen en voor me te zzien wat je bedoeld
Dus eigenlijk zou ik voor elke datum een tabel moeten aanmaken waarbij ik aangeef welke producten er die dag verhuurd zijn. Maar betekend dit dan niet dat die database per jaar 365 tabellen gaat krijgen?
Ik zou misschien een opschoonscript kunnen maken zodat oude tabellen verwijderd worden?
Mijn voorstel komt neer op het volgende: houd ergens tevens expliciet bij dat iets uitgeleend is (en aan wie) in plaats van dat je dit elke keer moet afleiden aan de hand van een complexe rekensom.
EDIT: dit lijkt mij in eerste instantie om te tracken waar alles is en te kijken of je voorraad nog klopt? Je zou hier natuurlijk ook nog een stapje verder mee kunnen gaan, je zou het systeem ook zou uit kunnen bouwen dat je items/onderdelen op den duur kunt reserveren/inplannen. In dat geval zul je het "in gebruik zijn" van items moeten koppelen aan tijd. Hier hoef je niet allerlei aparte tabellen voor aan te leggen lijkt mij. Wel lijkt het mij handig om dan tijd in partjes (dagen, dagdelen, uren?) op te delen.
Het gaat vooral om het laatste. Vooral in de drukke maanden zijn er vaak klussen die lang duren, waardoor ik het overzicht kwijt raak.
Ik zat zelf nog aan iets te denken om aan het begin van het overzicht eerst te checken welke andere opdrachten er binnen dit tijdsbetek zijn en dan alleen met die opdrachten te werken.
Nee dit is onzin, het systeem moet dan nog steeds alle ingeboekte producten bekijken om te kijken of ze bij een andere opdracht horen.
Misschien toch dan een tabel per dag.
Naar aanleiding van de laatste toevoeging.
Betekend dit dan dat als ik een product opsla ik dit per tijdsvak moet doen?
Een tijdsvak bij ons is altijd 1 dag.
Dus als ik een klus heb van 21 dagen waarbij we 20 podiumdelen nodig hebben, dat ik dan dit product 21 keer opsla?
Aangenomen dat je enkele weken tot maanden vooruit moet kunnen plannen, zou ik een koppeltabel maken met drie kolommen: datum, opdracht-ID en artikel-ID (als samengestelde primaire sleutel). Je hebt dan weliswaar deels redundante data, maar daar staat een performancewinst tegenover: je kunt per dag exact zien welk artikel voor welk project staat ingepland. Je kunt die tabel bovendien klein houden: doordat je uitgaat van redundante data, kun je alles dat meer dan enkele dagen oud is weer weggooien.
Meestal worden opdrachten niet eerder dan een jaar doorgegeven.
Maar dit tabel kan wel nog steeds zo'n 3 miljoen regels bevatten. Kan een website dit aan?
Ja, daar zou je dan ook aantallen in kunnen opslaan.
Drie miljoen kleine records mogen geen probleem zijn voor MySQL, MariaDB, enzovoort. Soms kun je beter te veel opslaan als dat betekent dat je daarmee processortijd bespaart in het doorrekenen van complexe vergelijkingen.
Geen idee, het leek mij veel werk voor een website om dit allemaal te checken.
Ik zou het zonde vinden om dit helemaal te gaan maken om vervolgens te horen dat dit idee heel slecht is omdat het te traag wordt.
Ander vraagje, is het mogelijk om een automatisch script te maken dat deze tabellen leeg haalt? Of zal ik het opschoonscript in de index.php zetten zodat hij dit script uitvoert op het moment dat de website bezocht wordt?
