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:
Ein Kunde macht die Angaben zu den Artikeln, das sind ja die eigentlichen Daten die Ich speichern will, mal ein Beispiel:
// Tabellen
// +- Spalten
Event
+- id
+- start
+- ende
+- ansprechpartner
Kunde
+- id
+- name
+- email
Artikel
+- id
Angaben_zu_Artikel
+- id
+- artikel_id
+- text
Kunden_zu_Event
+- event_id
+- kunden_id
Artikel_zu_Event
+- event_id
+- artikel_id
Angaben
+- angaben_zu_artikel_id
+- kunden_id
+- wert
ich habe jetzt 1 Event, vielleicht 10 Kunden(wobei die Zahl nicht direkt was mit dem einen Event zu tun hat), und 12 Artikel(hier ebenfalls nicht), 10 Kunden_zu_Event, 12 Artikel_zu_Event, im Schnitt 8 Angaben pro Artikel, also ca. 100 Angaben_zu_Artikel, und da jeder Kunde Angaben zu jedem Artikel und hier zu jeder Angabe macht, bekomme ich mal eben 1000 Angaben.
So komme ich sehr schnell an sehr viele Datensätze! Muß das sein? Denn schneller als man denkt ist man dann über 1 Mio, OK, das ist noch nicht wirklich kritisch, vor allem da die Tabellen sehr einfach sind, aber trotzdem, sehr wohl ist mir dabe nicht!
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.
Verstehe ich nicht. ich habe jeweils 1:n beziehungen, und in der Angaben-Tabelle 1:m - Beziehungen, oder? Was könnte ich da großartig dran ändern? Und - was bedeutet hier Redundanz? Ich kennen nur redundante Serveranbindungen(was IMHO heißt das der Server über mehr als 1 Leitung angebunden ist)?!
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.
Das wäre das DB-Layout, ist das stimmig?
Daten-Konsistenz...
Die ist bei MySQL grundsätzlich ein Problem, da Foreign Keys (bisher) nicht unterstützt werden.
Kann ich nicht manuell in jede Tabelle entsprechende Spalten mit den verknüpften Ids wür andere Tabellen einfügen? z.B. überall wo sinnvoll die ArtikelID, oder die KundenID? Oder ist das dann nur Datenmüll?
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.
Ich verwende fast immer nur left join, um die gewünschten zusätzlichen Daten zu gelangen!
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.
Es gibt insert-select, mal gucken ob das was bringt! Ich bräuchte ja ein Kriterium nach dem ich irgenwas auswähle, anders geht es glaub ich nicht, wie gesagt, ist das alles Neuland für mich!
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...
http://de.mysql.com/documentation/mysql/bychapter/manual.de_Deutsch.html#ANSI_diff_Transactions
http://de.mysql.com/documentation/mysql/bychapter/manual.de_Reference.html#Transactional_Commands
Aber ich habe keine Ahnung... wie gesagt, ich müßte mich einarbeiten, aber meiens Wissens unterstützt selbst 3.x Transaktionen in gewissem Umfang, hat da jemand Erfahrung mit?
Viele Grüße
Andreas