[mysql] database structureren

[maartenvdv737]

Ik ben bezig met een systeem opzetten om bedrijfsplannen in op te slaan.

Nu ben ik bezig om mijn database via de regels van Third Normal Form te structureren.

Een voorbeeld:

Tabel: Concurrent
Kolommen: id contact name address city postcode postbus email tel fax

Tabel: Klant
Kolommen: id brancheID contact name address city postcode postbus email tel fax

Tabel: Branche
Kolommen: id name

Tabel: Marketing
Kolommen: id name

Tabel: Mark_relations
Kolommen: id mark_id conc_id (ID van concurrent)

Zo heb ik nog meer tabellen zoals marketing, allemaal met een relations tabel, waarin de relatie tussen de concurrent of de klant worden gekoppeld aan een row in marketing, of andere tabellen.


Nu vind ik dit een zeer duidelijk en overzichtelijke structuur, maar nu kom ik bij het punt: invoeren van data.

Als ik via een form, een gebruiker al deze informatie wil laten invoeren, dus: gegevens in "concurrent" en welke marketing strategiën deze concurrent gebruikt. Dan krijg ik voor mijn gevoel immens ingewikkelde INSERT queries, en bovendien moet ik dan een aantal queries achter elkaar uitvoeren.


Doe ik dit zelfde verhaal in de First Normal Form, dan hoef ik slechts 1 tabel te maken, met alle eigenschappen, en die invoeren met ofwel een string, ofwel een 0/1 voor ja/nee. Bij het uitlezen hoef ik ook maar 1 query te doen, en ik kan alle objecten van de concurrent zo opvragen.

Mijn vraag is: Lijkt het nou moeilijker dan het is en kan ik nieuwe informatie ook met de TNF structuur goed invoeren, of is deze structuur niet toepasselijk voor de informatie die ik wil opslaan.

edit:

de branche tabel heeft geen relations tabel, omdat elke klant maar in 1 branche vertegenwoordigd kan zijn, in tegenstelling tot marketing_methodes.

[Crazy D]

Met 1 query kan dit toch wel. En tjah 1 tabel is makkelijker nu, maar ga je spijt van krijgen
En ach hoe moeilijk is het om de gebruiker een invoerveld en een dropdown te geven, om of een nieuwe branche in te laten voeren, of er eentje te selecteren uit de lijst. Hoe het onderhoud moet werken vind ik toch niet echt een criterium om wel of geen aparte tabellen te gebruiken, en in dit geval helemaal niet En 2 of 3 queries om dit te onderhouden zijn nou echt niet echt een vette bottleneck te noemen (tenzij je database wel heel brak is of je een supertrage lijn naar die database hebt liggen). En ook dan trouwens vind ik dat geen critirium om het in 1 tabel te doen

[maartenvdv737]

Hmm, ik vraag me toch sterk af of ik dit met 1,2,3 queries kan doen, aangezien ik nu 4 relations tabellen heb.

Maar misschien komt dat omdat ik de sql basics wel in de vingers heb, maar niet de leuke trucjes.

Heeft iemand soms een tip voor een query in deze situatie?

[dusty]

Ik kan het nog wel lastiger maken voor je

Je hebt nu 2 tabellen: Concurent en Klant, in principe zit er bij jou maar een verschil in: brancheID. Echter kan een concurent ook een andere branche hebben dan jou maar toch nog steeds als concurent gezien worden, echter zijn er ook concurenten van je die tegelijkertijd toch klant kunnen zijn. De twee tabellen slaan dus dezelfde soort informatie op.

Nu voor je vraag: Het lijkt moeilijker dan het is.

Vooral voor het onderhoudbaarheid is het beter aangezien als er nieuwe informatie is, kan je dat makkelijker toevoegen als je hebt genormaliseerd. En als je niet hebt genormaliseerd moet je elke keer je datamodel aanpassen (wat dus ingrijpender is.).

[ Voor 0% gewijzigd door dusty op 06-09-2002 22:18 . Reden: taalfoutjes ]

[maartenvdv737]

Ik kwam nog op een nieuw idee. Is het niet handiger om 1 relations tabel te maken, waarin
alle relaties tussen de klant/concurrent en de overige tabellen staan?

[dusty]

Handiger, Veiliger, Slimmer, Makkelijker. Maar dat is het vaak als je correct normaliseert

[maartenvdv737]

Dusty, goed idee nog van die klant en concurrent, ik heb daar nu van gemaakt: company en comp_relations.

Maar omdat de normale tabellen (waarvan de relation tabellen de relaties bevatten met de company tabel) meerdere rows hebben voor dezelfde comp_id, gaat dan de algemene tabel: relations, niet ontzettend hard groeien?

Die tabellen bevatten namelijk successievelijk 7,1,1,4,5,4 mogelijkheden (rows)

Voor 1 concurrent heb ik dan maximaal: 7 * 1 * 1 * 4 * 5 * 4 = 560 rows nodig!

Stel dat ik 1000 concurrenten en 1000 klanten heb, dan heb ik dus 1.1 Miljoen rows in mijn relation tabel staan.

Dus ik vraag me af of het inderdaad handiger en slimmer is??

Hier een voorbeeld zoals het is met losse relation tabellen, met helemaal onderaan hoe het zou zijn met 1 relation tabel:
http://maartenvdv.has.it

[dusty]

Als eerste stap zou je kunnen overwegen om na te lopen of je alles wel goed hebt genormaliseerd. (lees: ik zie op zijn minst al een fout.)

[maartenvdv737]

Hmm, ik heb nog eens goed gekeken, maar het enige wat ik zie in die relations tabel is dat concurrent/customer misschien weg moet daar.