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.
?
Onbekende gebruiker
02-07-2016 21:19
@J, mijn eerste gedachte is om een kalendertabel te maken waarin per dag alle reserveringen staan, die je kunt koppelen met de inventaristabel. Samen met indices moet dat systeem echt snel te doorzoeken zijn, omdat je alleen een bepaalde periode doorzoekt en niet de hele tabel. Je kunt dan de standaard-aggregatiefuncties van SQL gebruiken om te bepalen of producten voorraddig zullen zijn.
Ik dacht dat het iets speciaals was. MEt al die nieuwe functies in php en mysqli vind ik het moeiilijk bij te houden.
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.
In die zin kan timetravel mogelijk ook nuttig zijn, dan kun je gewoon je totale inventaris - op dit moment op locatie = beschikbare inventaris doen: je hebt een id van je inventaris, een startdatum van uitboeking, einddatum van uitboeking (of NULL indien uitgeboekt maar niet bekend wanneer deze terug is). Wanneer de einddatum groter is dan de huidige datum en de startdatum kleiner is dan de huidige datum is dit product niet voorradig.
Het is voornamelijk interessant om direct een geschiedenis mee te vormen van wat er met je inventaris gebeurd is. Hier is timetravel ook voornamelijk voor bedoeld, maar zoals mijn voorbeeld aangeeft kun je hiermee je berekeningen ook eenvoudiger maken van opzet door te bepalen wat *nu* niet voorradig is. Vooral in het geval dat je schetst dat te technische voorraad constant is maar de economische voorraad wijzigt is dat handig. Het bijkomend voordeel is dat je een half jaar of desnoods 10 jaar later nog kan zeggen "zo was de voorraad van product X op datum/tijd X".
Jij niet, maar je verzekering wel, en de bank ook.
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.
