nicht angemeldet
Hi,
Ich habe jeweils ein "Event". diesem Event ordne ich mehrere "Kunden" und mehrere "Artikel" zu. Jeder Kunde kann dann mehrer Angaben zu einem Artikel machen.
2. die Angaben zu den Artikeln. Problem hier, diese Angaben sind nicht immer gleich, d.h. der eine Arikel hat die Angaben A,B,D, der andere A,C,E,F,G,Y.... das ist bei jedem Artikel anders.
ich bin jetzt nicht ganz sicher, ob zwischen "Kunden" und "Artikel" eine Verknüpfung sein soll. Wenn nicht, sind die Beziehungen etwa so:
Kunden -> Event <- Artikel <- Angaben
Ob Du jetzt im einzelnen (insb. zwischen Artikel und Angaben) 1:n- oder n:m-Beziehungen baust, hängt von der daraus resultierenden Redundanz ab.
Was ist dann mit Performance,
Die hängt von mehr Faktoren ab - besonders auch Indizes und Statements - ab. Das DB-Layout muss _insgesamt_ stimmig sein.
Daten-Konsistenz...
Die ist bei MySQL grundsätzlich ein Problem, da Foreign Keys (bisher) nicht unterstützt werden.
vor allem wenn ich dann Joins über 3, 4 und mehr Ebenen verwende?
Joins über 20 Tabellen sind kein wesentlich größeres Problem als solche über 2 Tabellen, was die Konsistenz betrifft. Du musst _immer_ aufpassen (bei MySQL), dass die Daten richtig geschrieben werden. Die Statements lassen sich (nämlich ohne Outer Joins) so gestalten, dass nur "vollständige" Datensätze geliefert werden.
Außerdem ist es wohl nicht ganz optimal andauernd zig Inserts über verschachtelte Schleifen im Code stehen zu haben,
Ja, das ist richtig. Ich bin nicht ganz sicher, ob MySQL muliple Inserts in einem Statement erlaubt; das verrät Dir die Doku. Pro Tabelle brauchst Du in dem Fall nur noch ein Statement.
Wäre jetzt vielleicht der Zeitpunkt gekommen mich mal mit Transaktionen auseinander zu setzen?
Soweit ich weiß ist das auch nicht gerade eine MySQL-Stärke...
Cheatah