Twijfels over opzet database

[azerty]

.

De applicatie loopt wel vlot, maar omdat ik ondertussen veel bijgeleerd heb ben ik van plan zowel de database als de site zelf aan te pakken binnenkort. Ik heb in een kopietje van het origineel ondertussen wat dubbels weggehaald, maar ik zit nog met 1 grote vraag op dit moment:

.

Op dit moment sla ik het op in 50 velden, waarvan die variabele data gewoon met een | gejoined wordt en dan opgeslagen is in een veld.

Ik vraag me dus af hoe dit eventueel beter kan, want ik kan niet echt een betere manier verzinnen op dit moment...

Voorbeeldje van formulier:

vast veld

vast veld

*snip*

aantal bedrijven: 3

Bedrijf 1: variabel veld 1, variabel veld 2, ...

Bedrijf 2: variabel veld 1, variabel veld 2, ...

Bedrijf 3: variabel veld 1, variabel veld 2, ...

aantal wagens: 3

Wagen 1: variabel veld 1, variabel veld 2, ...

Wage 2: variabel veld 1, variabel veld 2, ...

Wagen 3: variabel veld 1, variabel veld 2, ...

=> Dit wordt dus opgeslagen als:
wagens_veld1: wagen1_waarde|wagen2_waarde|wagen3_waarde...
...

[ Voor 22% gewijzigd door azerty op 08-11-2014 23:32 ]

[Paul]

wsitedesign schreef op vrijdag 02 maart 2012 @ 14:48:
Als een persoon een rapport invult, dan vult hij een form in waar (hangt van case tot case af) van +-50 velden tot een goede 500+ velden in kunnen staan, waar het variabele gedeelte een herhaling is van een bepaald stuk, maar de data verschilt natuurlijk.

Klinkt als een goede kandidaat om een eigen tabel te verdienen

Tabel met "vast veld 1" en "vast veld 2", een tabel met bedrijven (die je koppelt aan de persoon die je noemt), een tabel met wagens...

Wikipedia: Entity-relationship model Iedere entiteit is (vaak, maar niet altijd) kandidaat om een tabel te worden, en afhankelijk van de koppeling ertussen is iedere relatie een foreign key in één van de 2 entiteiten die gekoppeld worden of een koppeltabel.

[NMe]

Je hebt een database in een database, en dat dan ook nog eens op de minst elegante manier.

Je bent beter af als je gewoon normaliseert en een tabel maakt voor bedrijven, een voor wagens, een voor... enz. Of als dat niet dynamisch genoeg is: verder doornormaliseren en dus een tabel overhouden waarin je alle entiteittypes in opslaat en vervolgens met (koppel)tabellen alles aan elkaar plakken.

[azerty]

Hartelijk bedankt alle twee!

Ik zal inderdaad voor een oplossing gaan in de vorm van een extra tabel, dit zal de beste oplossing zijn waarschijnlijk, en het ziet er ook een goede methode uit. Ik was eigenlijk gewoon aan het twijfelen omdat het an-sich tot het . behoort en dus "logisch" gezien in dezelfde tabel zou moeten zitten (althans voor een normale persoon, het klopt inderdaad dat bij normalisatie zo'n zaken gesplitst worden).

[NMe]

Het meest traditionele praktijkvoorbeeld van normalisatie is nog altijd het opsplitsen van orders en orderregels. Je hebt dan één record voor je object en elke regel uit de order heeft een eigen record in de tweede tabel. Dat iets visueel bij elkaar hoort is geen reden om het niet op te splitsen.

[Paul]

Het hoort voor jou misschien tot het rapport, maar je vader is helemaal niet geïnteresseerd in rapporten; hij wil geen stapel rapporten op zijn bureau omdat hij rapporten zo leuk vindt, hij wil weten hoeveel en welke auto's iemand heeft en hoeveel bedrijven, -dat- is je informatie

[azerty]

*snip*

[ Voor 102% gewijzigd door azerty op 14-01-2015 01:57 ]