Hé tweakers,
In het verleden hebben we een applicatie met een achterliggende database geschreven. Momenteel gaan we beginnen aan een revisie van deze applicatie en uitbreiding van de database is hier ook een onderdeel van. Ik twijfel echter soms of het ontwerp wel helemaal goed is, dus ik zou het op prijs stellen als er eens wat meer mensen hun mening over zouden willen geven.
Het gaat om een MySQL database, met behulp van een export via PHPMyAdmin en een import in MySQL Workbench, is daar het volgende EER diagram uitgekomen (klik voor een grotere afbeelding):
Met enkel een plaatje en geen uitleg, kan er natuurlijk moeilijk feedback gegeven worden, dus hier volgt de uitleg van de applicatie.
Het bedrijf waar ik werk maakt vacuümverpakking machines, ze hebben een aantal verschillende series en daarbinnen een aantal diversen modellen ('types' in het ontwerp). Binnen elk model heb je diversen opties voor diversen onderdelen van de machine. Het is echter niet zo dat bij elk model de opties hetzelfde zijn. De verschillen in onderdelen en opties zijn er in grote lijnen per serie, maar vaak ook nog specifiek per model. De keuze is gemaakt om deze dan ook op basis van model vast te leggen. Afhankelijk van gekozen antwoorden, rollen er diversen artikelnummers uit de database die samen een machine vormen. Soms is een onderdeel afhankelijk van één gekozen optie, terwijl deze ook afhankelijk kan zijn van meerdere gekozen opties.
Al die combinaties zijn onmogelijk te onthouden voor de mensen van verkoop. Het gaat dan om enkele duizenden combinaties die mogelijk zijn. Vandaar is er een productconfigurator geschreven, dit is een klein stukje software binnen het ERP pakket, waarmee aan de hand van vragen en antwoorden de juiste artikelen samengevoegd worden.
Hoe is de opbouw van de database nu verder?
Hetgeen mij enorm stoort is dat wanneer een onderdeel van verschillende opties afhankelijk is, er eigenlijk altijd een nieuwe tabel nodig is. Vaak komen de opties waarvan de onderdelen afhankelijk zijn wel overeen, maar bij het ene onderdeel heeft een bepaalde optie wel invloed en bij een andere niet.
Voorbeeld:
Sealbalken en sealtrafo's zijn nagenoeg gelijk, maar bij de sealtrafo's is de pomp keuze wel van invloed en bij de sealbalken niet. Daarnaast is er nog wat extra informatie gewenst bij sealtrafo's buiten het aantal, die voor de sealbalken niet nodig is.
In de toekomst gaan we meer van dit soort onderdelen uitwerken en ik zit me dus af te vragen of hier een betere oplossing voor te bedenken is dan hoe het nu gaat. Ook omdat bij een nieuw onderdeel met diversen combinaties er handmatig een tabel bijgemaakt moet worden, nieuwe pagina's geschreven moeten worden, zodat men de koppeling tussen type, gekozen antwoorden en onderdelen kan leggen.
Gewenste feedback
Voor mijn gevoel zit hij van de ene kant dus wel goed in elkaar, maar van de andere ook weer niet. Kunnen jullie er eens naar kijken en dan een antwoord proberen te geven op de onderstaande vragen?
- Hebben jullie een betere oplossing voor het hierboven beschreven probleem?
- Zie je nog op andere plekken in het diagram punten voor verbetering? (Alle tips zijn welkom!)
In het verleden hebben we een applicatie met een achterliggende database geschreven. Momenteel gaan we beginnen aan een revisie van deze applicatie en uitbreiding van de database is hier ook een onderdeel van. Ik twijfel echter soms of het ontwerp wel helemaal goed is, dus ik zou het op prijs stellen als er eens wat meer mensen hun mening over zouden willen geven.
Het gaat om een MySQL database, met behulp van een export via PHPMyAdmin en een import in MySQL Workbench, is daar het volgende EER diagram uitgekomen (klik voor een grotere afbeelding):
Met enkel een plaatje en geen uitleg, kan er natuurlijk moeilijk feedback gegeven worden, dus hier volgt de uitleg van de applicatie.
Het bedrijf waar ik werk maakt vacuümverpakking machines, ze hebben een aantal verschillende series en daarbinnen een aantal diversen modellen ('types' in het ontwerp). Binnen elk model heb je diversen opties voor diversen onderdelen van de machine. Het is echter niet zo dat bij elk model de opties hetzelfde zijn. De verschillen in onderdelen en opties zijn er in grote lijnen per serie, maar vaak ook nog specifiek per model. De keuze is gemaakt om deze dan ook op basis van model vast te leggen. Afhankelijk van gekozen antwoorden, rollen er diversen artikelnummers uit de database die samen een machine vormen. Soms is een onderdeel afhankelijk van één gekozen optie, terwijl deze ook afhankelijk kan zijn van meerdere gekozen opties.
Al die combinaties zijn onmogelijk te onthouden voor de mensen van verkoop. Het gaat dan om enkele duizenden combinaties die mogelijk zijn. Vandaar is er een productconfigurator geschreven, dit is een klein stukje software binnen het ERP pakket, waarmee aan de hand van vragen en antwoorden de juiste artikelen samengevoegd worden.
Hoe is de opbouw van de database nu verder?
- We hebben series en types (de modellen), deze zijn met elkaar verbonden. (linksboven in de afbeeldingen)
- We hebben vragen en antwoord teksten, deze geven de keuzes voor de onderdelen die in een machine kunnen zitten. Deze liggen, per type, gekoppeld in antwoorden en de volgorde van de vragen en de antwoorden kan bepaald worden. (rechtsboven in de afbeelding)
- We hebben productgroepen en producten, dit spreekt voor zich. Het veld artikelnummer in producten bevat het werkelijke artikelnummer uit het ERP pakket. (rechtsonder in de afbeelding)
- Alle andere tabellen in de afbeelding, met uitzondering van die aan de rechterkant, zijn koppelingen tussen vragen, antwoorden, types en producten.
- Sommige onderdelen zitten altijd in een type, tabel basisonderdelen.
- Sommige onderdelen zijn afhankelijk van een enkele vraag, tabel simpel (enkelvoudig zou een betere naam zijn)
- De overige onderdelen zijn afhankelijk van een combinatie van vragen, antwoorden en type. De tabellen sealtrafo's, sealbalken en componentplaten. Een aantal van de tabellen aan de rechterkant zijn ook van dit type, maar zijn nog niet geïmplementeerd
- Verder hebben we nog wat lossen tabellen, die niet rechtstreeks invloed hebben op de onderdelen die eruit rollen, maar meer administratief zijn zoals users en logs.
Hetgeen mij enorm stoort is dat wanneer een onderdeel van verschillende opties afhankelijk is, er eigenlijk altijd een nieuwe tabel nodig is. Vaak komen de opties waarvan de onderdelen afhankelijk zijn wel overeen, maar bij het ene onderdeel heeft een bepaalde optie wel invloed en bij een andere niet.
Voorbeeld:
Sealbalken en sealtrafo's zijn nagenoeg gelijk, maar bij de sealtrafo's is de pomp keuze wel van invloed en bij de sealbalken niet. Daarnaast is er nog wat extra informatie gewenst bij sealtrafo's buiten het aantal, die voor de sealbalken niet nodig is.
In de toekomst gaan we meer van dit soort onderdelen uitwerken en ik zit me dus af te vragen of hier een betere oplossing voor te bedenken is dan hoe het nu gaat. Ook omdat bij een nieuw onderdeel met diversen combinaties er handmatig een tabel bijgemaakt moet worden, nieuwe pagina's geschreven moeten worden, zodat men de koppeling tussen type, gekozen antwoorden en onderdelen kan leggen.
Gewenste feedback
Voor mijn gevoel zit hij van de ene kant dus wel goed in elkaar, maar van de andere ook weer niet. Kunnen jullie er eens naar kijken en dan een antwoord proberen te geven op de onderstaande vragen?
- Hebben jullie een betere oplossing voor het hierboven beschreven probleem?
- Zie je nog op andere plekken in het diagram punten voor verbetering? (Alle tips zijn welkom!)
/u/249034/arrow.png?f=community){kind=icon}
/u/44276/got_icon5.png?f=community)
/u/3273/crop62bb0d316df4f_cropped.png?f=community)