Inventaris systeem
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.
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?
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.
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?
Gewijzigd op 02/07/2016 13:41:46 door J C
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.
Gewijzigd op 02/07/2016 13:48:20 door Thomas van den Heuvel
Het gaat vooral om het laatste. Vooral in de drukke maanden zijn er vaak klussen die lang duren, waardoor ik het overzicht kwijt raak.
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?
Gewijzigd op 02/07/2016 13:56:29 door J C
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?
Gewijzigd op 02/07/2016 14:05:38 door J C
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.
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?
J C op 02/07/2016 22:34:20:
wat is een kalendertabel? Ik denk niet dat mijn provider dit ondersteund, want ik kan het in myadmin niet vinden
Eh.... een tabel is doorgaans wat je zelf moet aanmaken. Lees zijn post nog eens goed?
Het idee dat ik nu heb (mede dankzij jullie hulp) is als volgt:
Ik maak een "reken"tabel met de volgende velden:
ID | product-ID | datum (in dit geval enkel de dag/maand/jaar) | aantal
Wat betekend dat wanneer ik een opdracht invoer ik per dag een regel invoer, bij een nieuwe boeking check ik of dit product op deze dag al bestaat en tel het nieuwe aantal hierbij op.
Bij het wijzigen van een opdracht (iets dat regelmatig gebeurt) zal ik eerst het aantal verwijderen en dna opnieuw invoeren. Het enige gevaar is dat wanneer er verschillende opdrachten zijn , ik niet in dit tabel kan achterhalen waaruit dit aantal is opgebouwd.
Dit kan uiteraard wel met het andere tabel waarin de producten met opdracht-id staan vermeld.
Gewijzigd op 02/07/2016 22:49:06 door J C
Maar het kan zijn dat ik me totaal vergis.
Ik kan er niet heel veel over vinden, maar dat komt denk ik ook omdat de naam ook gebruikt wordt bij diverse app´s
Gewijzigd op 03/07/2016 02:20:16 door J C
Ik wil wel aangeven dat ik het totaal niet interessant vind om te weten of ik 10 jaar geleden een voorraad tekort had.
Gewijzigd op 03/07/2016 13:40:48 door J C
Anyway: zoeken op iets als temporal tables of timetravel with temporal tables kan hier uitkomst bieden.
als die al iets zou willen weten over mijn inventaris dan gaat die om totalen en niet om beschikbaarheid.
Mijn bank heeft niets te willen.
Maar los daarvan, dit gaat om een beschikbaarheidsplanning niet om een boekhoudprogramma, dit zou ik nooit zelf kunnen/willen bouwen.
Toevoeging op 04/07/2016 02:26:55:
Mijn vorige post is verwijderd, weet niet precies waarom.
Kort samengevat:
Na lang nadenken denk ik dat wanneer ik zonder unique id steeds producten bij elkaar optel en van elkaar aftrek ik op een gegeven moment het overzicht kwijt ben, omdat ik dit ook moeilijk kan terug halen, ondanks dat het een extra tabel is.
Mijn idee is nu om een tabel te maken als volgt:
id | boekingid | productid | datum | aantal
Ik kan dan selecteren op datum.
De ervaring zal moeten leren of het rekenwerk de snelheid niet te veel beinvloed.