[EXCEL & MySQL] Referentiele integriteit *

[N3vS]

De situatie is als volgt

Ik heb een website gemaakt voor een klant. Deze klant levert zo'n 5000 verschillende producten verdeeld over zo'n 100 merken en 12 categorien.

Nou heeft mijn klant voor elke catagorie een aparte excel sheet, deze sheets krijgt de klant aangeleverd van zijn leverancier.

Die excelsheets worden 1 of 2 keer per jaar aangepast (de prijzen) en daarna moet het allemaal weer op internet komen in een MySQL database. Nou is het exporteren van excel naar MySQL voor mij niet zo'n heel groot probleem, maar hij maakt voor elke categorie een aparte tabel aan en elke merknaam komt meerdere keren voor in 1 tabel. De database voldoet dan niet meer aan zijn referentiele integriteit.

Ik zit er over na te denken om excel te exporteren naar XML en daarna m.b.v. een PHP pagina deze te importeren in MySQL met daarbij de juiste informatie in de juiste tabellen.
Of zou ik die referentiele integriteit kunnen verwaarlozen? Het nadeel hiervan is dan de (slechte) perfomance lijkt mij. Of zitten hier nog meer nadelen aan?

Ik zit erg verlegen om advies

Gr. Sven

[ Voor 1% gewijzigd door N3vS op 06-05-2005 11:15 . Reden: Wou topic naam veranderen :s ]

[gorgi_19]

Geef even een suggestie voor een goede titel via

Wat heeft referentiele integreteit verder met performance te maken? Ondersteunt MySQL wel referentiele integriteit; bedoel je niet indexen?

[ Voor 25% gewijzigd door gorgi_19 op 06-05-2005 11:18 ]

[N3vS]

Misschien is referentiele integriteit geen goed woord, maar een database kan je normaliseren met als doel om alle data in de database 1 keer op te slaan. Informatie/gegevens die meerdere keren voorkomen kan je normaliseren en meestal betekend dat er een aparte tabel voor komt.

Ik heb de database dus genormaliseerd, maar als ik excel direct exporteer naar MySQL dan verdwijnt die 'normalisatie' en heb ik eigenlijk een foutieve database waarbij informatie/gegevens meerdere keren voorkomt.

Nou is mijn vraag of dit verstandig is, om met een niet-genormaliseerde database te werken, of dat ik tegen problemen ga aanlopen die ik zelf op dit moment nog niet zie.

[ Voor 17% gewijzigd door N3vS op 06-05-2005 11:24 . Reden: spelfouten ]

[gorgi_19]

Ik weet wat normaliseren is en wat referentiele integriteit is. Alleen zie ik de relatie niet met performance. Hoe beter genormaliseerd een database is, hoe slechter de performance is; hoewel dit bij de eerste drie normaalvormen normaliter wel mee gaat vallen.

Of het erg is of niet? Tsja, als je applicatie zo gebouwd is dat het niet uitmaakt hoe de basis opgehaald wordt, waarom zou je dan heel veel moeite doen om te gaan normaliseren? Als tussendoor geen gegevens gewijzigd worden, behalve 2 keer per jaar, waarbij alles in een keer gewijzigd wordt, zie ik weinig reden om je complete bronbestand om te gaan gooien.

Ga je er van uit dat je later of tussendoor wel nog gegevens moet kunnen invoeren of aanpassen, nieuwe leveranciers toevoegen, opzoeken welke producten een leverancier allemaal levert, of omgekeerd, dan is normalisatie wel aan te bevelen. Puur presentatie van domme data op 1 wijze hoef je geen normalisatie op toe te passen, imho. Wil je bovendien nog correctheid van gegevens afdwingen, dan kan je referentiele integreteit ook nog gaan afdwingen. (dus dat een product een bestaand leverancierId moet hebben bijvoorbeeld).

[ Voor 32% gewijzigd door gorgi_19 op 06-05-2005 11:28 ]

[N3vS]

gorgi_19 schreef op vrijdag 06 mei 2005 @ 11:26:
Of het erg is of niet? Tsja, als je applicatie zo gebouwd is dat het niet uitmaakt hoe de basis opgehaald wordt, waarom zou je dan heel veel moeite doen om te gaan normaliseren? Als tussendoor geen gegevens gewijzigd worden, behalve 2 keer per jaar, waarbij alles in een keer gewijzigd wordt, zie ik weinig reden om je complete bronbestand om te gaan gooien. ...

Dus je bedoelt eigenlijk gewoon Excel omzette naar MySQL en verder niet meer aan zitten? Voor elke categorie een eigen tabel en niet druk maken omdat 1 merknaam 50x voorkomt in die tabel.

Scheelt wel een hoop kopzorgen, ik maak me beetje zorgen om het feit dat ik me niet goed kan voorstellen tegen wat voor problemen ik kan tegen oplopen, meestal betekend dit dat ik erg veel over het hoofd zie, vandaar dit topic.

[ Voor 1% gewijzigd door N3vS op 06-05-2005 11:35 . Reden: quote werkte niet ]

[curry684]

MySQL ondersteunt geen declarative referential integrity (DRI). Dat wil zeggen: je mag het wel declarareren, maar hij negeert het vervolgens. DRI is dan ook enkel bedoeld om de consistency (de C van ACID) van je database te bewaken doordat het niet toestaat dat je een row met primary key X weggooit zolang er nog tables een foreign key op X hebben, of optioneel een cascading delete of cascading update uit te voeren.

Op performance zelf heeft het geen invloed, zelfs waarschijnlijk een ongewenste licht positieve omdat de checks er niet in zitten. De performance van joins leunt voor 99% op de aanwezigheid van indexes, wat ook de reden is dat een foreign/primary key vrijwel per definitie voorzien dient te zijn van een index. De index staat het DBMS vervolgens toe om de te joinen rows razendsnel bij mekaar te vinden.

Als je regelmatig een zooi data weggooit en opnieuw via DTS, Excel imports oid binnentrekt is je DRI sowieso een puinzooi, daar is helaas niet echt veel aan te doen. Met indexen kun je vervolgens alsnog je performance op het hoogste peil trekken