[Applicatie / Database] Tips / tricks gevraagd voor ontwerp

[Crazybyte]

Ik heb hier al eens eerder een topic over geopend, maar het project heeft daarna een hele tijd stil gelegen, nu het weer is opgepakt, loop ik nog altijd tegen hetzelfde probleem aan. Ik hoop dat, met een betere uitleg vanuit mijn kant, jullie mij een eindje op weg kunnen helpen.

Wat voor applicatie is het?
Het gaat om een zogenaamde productconfigurator (PCF). Deze toont een lijstje met vragen en antwoorden aan een gebruiker, de gebruiker selecteert de gewenste antwoorden op de vragen en klikt vervolgens op genereren. De PCF stelt vervolgens een lijst van artikelen samen, die samen het uiteindelijke product vormen.
Met deze PCF stellen we in ons geval machines samen, er zijn een aantal series, met daarbinnen een aantal types. Per type moeten er dan nog allerlei vragen over eigenschappen en opties van de machine gekozen worden.

Wat is er nu mis?
Even naamgeving en type van velden / tabellen daargelaten (die is niet logisch en consequent gedaan), doet het systeem wat het moet doen. Dus in dat opzicht is er niets mis mee.
Er zit echter een vervelend stukje in de opbouw van het uiteindelijke product, wat er voor zorgt dat ik nu telkens extra tabellen aan maak, wanneer we voor een onderdeel van de machine de artikelen willen weten.

De opbouw van een machine is als volgt, stel ik heb 100 verschillende artikelen:

• Om artikel 1 t/m 20 te bepalen, wil ik enkel weten welke type machine het is
• Om artikel 21 t/m 25 te bepalen, wil ik weten welk antwoord gegeven is op vraag 1
• Om artikel 26 t/m 30 te bepalen, wil ik weten welk antwoord gegeven is op vraag 2
• ....
• Om artikel 56 t/m 60 te bepalen, wil ik weten welk antwoord gegeven is op vraag 8
• Om artikel 61 t/m 70 te bepalen, wil ik weten welke antwoorden er gegeven zijn op vraag 3, 4 en 5
• Om artikel 71 t/m 80 te bepalen, wil ik weten welke antwoorden er gegeven zijn op vraag 3 en 6
• Om artikel 81 t/m 98 te bepalen, wil ik weten welke antwoorden er gegeven zijn op vraag 2, 5 en 6
• Om artikel 99 te bepalen, wil ik weten welke antwoorden er gegeven zijn op vraag 3 en 6
• Om artikel 100 te bepalen, wil ik weten welke antwoorden er gegeven zijn op vraag 2, 5, 6, 7 en 8

Er zijn dus artikelen die enkel afhankelijk zijn van het type of enkel afhankelijk van één vraag en het daarbij gegeven antwoord. Daarnaast zijn er artikelen die afhankelijk zijn van een combinatie van vragen en de gegeven antwoorden daarbij. Tenslotte zijn er nog artikelen waarbij een combinatie van vragen en de gegeven antwoorden maar één artikel mag opleveren.

Het gaat me dus juist om de laatste 5 mogelijkheden uit het lijstje. Dan zijn het twee vragen, dan weer 3 en dan weer 6 en de ene keer mogen ze meerdere artikelen opleveren en de andere keer mogen ze maar één artikel opleveren.

Nu los ik dit dus op door voor elke combinatie een nieuwe tabel te maken, maar ik wil dit graag naar één tabel hebben en daar zoek ik een oplossing voor. Tevens op zo'n manier dat ik nieuwe combinaties kan maken, zonder dat ik nieuwe tabellen hoef toe te voegen.

Ik heb werkelijk al van alles bedacht, maar ik loop ik vast en weet ik niet hoe ik verder moet.

Hopelijk kunnen jullie mij hier wat tips / tricks in de goede richting geven, over hoe ik dit het beste kan aanpakken!

Tot dusver heb ik het onderstaande, maar het hele stuk tussen de type/vraag/antwoord combinatie en de uiteindelijke artikelen ontbreekt.

[ Voor 3% gewijzigd door Crazybyte op 21-04-2009 16:38 . Reden: tekst verplaatst ]

[Patriot]

Euh, het is toch een kwestie van een extra tabel met daarin twee id's en het antwoord? Eén id van de vraag in kwestie, één id van de vraag waarvan deze afhankelijk is, en het antwoord?

[Crazybyte]

Patriot schreef op dinsdag 21 april 2009 @ 18:19:
Euh, het is toch een kwestie van een extra tabel met daarin twee id's en het antwoord? Eén id van de vraag in kwestie, één id van de vraag waarvan deze afhankelijk is, en het antwoord?

Ik zou het op prijs stellen als je me uitlegt hoe je dat voor je ziet.

Momenteel zijn er namelijk extra tabellen voor:

• artikelen die op basis van het type kunnen worden bepaald
• artikelen die op basis van één vraag / antwoord combinatie kunnen worden bepaald
• artikelen die op basis van twee vraag / antwoord combinaties worden bepaald en onderdeel x van de machine vormen
• artikelen die op basis van twee vraag / antwoord combinaties worden bepaald en onderdeel y van de machine vormen
• artikelen die op basis van drie vraag / antwoord combinaties worden bepaald en onderdeel z van de machine vormen
• artikelen die op basis van drie vraag / antwoord combinaties worden bepaald, onderdeel v van de machine vormen, waarbij de combinatie van vraag / antwoord, maar 1 artikel mag opleveren. (Dus combinatie is uniek)

Ik heb wel zitten nadenken over een tabel waarin je vastlegt welke onderdelen van de machine je hebt en dat je vervolgens weer in een andere tabel opslaat welke vragen van belang zijn voor dat onderdeel, maar dan loop ik vast hoe het verder moet.

Waar ik ook nog aan heb gedacht is zorgen dat er per totale lijst van vragen en antwoorden, een unieke key is waar volgens artikelen aan hangen, maar dan kreeg ik veel dubbele relaties. Voor één van de meest simpele machines zijn er al 768 verschillende totaal lijstje mogelijk, dus dat is ook niet echt een optie.

[The Van]

Crazybyte schreef op dinsdag 21 april 2009 @ 16:36:
Nu los ik dit dus op door voor elke combinatie een nieuwe tabel te maken, maar ik wil dit graag naar één tabel hebben en daar zoek ik een oplossing voor. Tevens op zo'n manier dat ik nieuwe combinaties kan maken, zonder dat ik nieuwe tabellen hoef toe te voegen.

Zoiets heet een lookup table, en bvat (in jouw geval) alleen het vraag id en het artikel id. Als je perse wilt, kun je er een ID veld aanhangen, maar dat heeft geen enkel nut.
Kost de combinatie (vraag, artikel) voor dan (actie). Actie zul je zelf moeten invullen - ik neem aan, dat je dan het artikel juist nodig hebt.
Je zou dus opnemen:
100,2
100,5
100,6
100,7
100,8

Als ineens vraag 3 ook meedoet, maar 5 en 8 niet meer, dan 100,3 toevoegen, en 100,5 en 100,8 deleten.

[Crazybyte]

The Van schreef op vrijdag 24 april 2009 @ 14:07:
[...]

Zoiets heet een lookup table, en bvat (in jouw geval) alleen het vraag id en het artikel id. Als je perse wilt, kun je er een ID veld aanhangen, maar dat heeft geen enkel nut.
Kost de combinatie (vraag, artikel) voor dan (actie). Actie zul je zelf moeten invullen - ik neem aan, dat je dan het artikel juist nodig hebt.
Je zou dus opnemen:
100,2
100,5
100,6
100,7
100,8

Hier heb ik inderdaad ook over nagedacht, maar dan per onderdeel van de machine aangeven welke vragen daarvoor van belang zijn, maar dan moet ik dus nog ergens anders vastleggen welk artikel nu volgt uit welke combinatie van antwoorden bij dat onderdeel.

Dus bij onderdeel 100 van de machine:
(2:a, 5:c, 6:a, 7:b, 8:e) >> artikel 0040 1x
(2:b, 5:a, 6:g, 7:c, 8:e) >> artikel 0045 1x

Maar dan dus ook:
- onderdeel 28: (2:a) >> artikel 0020 1x
- onderdeel 28: (2:a) >> artikel 0021 2x
- onderdeel 75: (3:b, 6:a) >> artikel 0030 4x

* (cijfer:letter) = (vraag:antwoord)

En dat dan het liefst ook weer in één tabel, daar kwam en kom ik niet uit, waardoor ik dus ook die optie niet verder hebt uitgewerkt. Misschien kan het ook wel niet in één tabel, maar ik zoek dan in ieder geval naar een oplossing dat ik niet als straks ineens 4 vragen nodig zijn ik weer een nieuwe tabel moet maken.