nicht angemeldet
Hallo Andreas,
Tabelle "Angaben_zu_Artikel" // da müßte ich dann für jede möglcihe Angabe eine Datensatz mit der ArtikelID speichern, oder?
Tabelle "Angaben" // Daten der Kunden zu den jeweiligen Angaben zu den Artikeln, dann ebenfalls Zeilenweise mit Verknüpfung zur Angabe _und_ Artikel _und_ Kunde.
Wenn Du nicht über die Angaben selektieren mußt, sondern sie nur nach Kunden anzeigst, könntest Du die Angaben z.B. noch als xml in der Tabelle Artikel speichern, und dann im gleichen Format in der Tabelle
"Angaben", dann brauchst du die "Angaben zu Artikel" nicht, und in "Angaben" hast Du nur noch eine Zeile pro Artikel und Kunde.
Was haltet Ihr davon? Habe bisher noch keine solchen Datenbank-Designs benötigt, würdet Ihr das evtl. anders machen?
Nein, bis auf das oben nicht, soweit ich sehe.
Was ist dann mit Performance, Daten-Konsistenz... vor allem wenn ich dann Joins über 3, 4 und mehr Ebenen verwende? Außerdem ist es wohl nicht ganz optimal andauernd zig Inserts über verschachtelte Schleifen im Code stehen zu haben, das kommt mir jedenfalls so vor als würde ich mir da viele potentielle Fehlerquellen einbauen!
Joins über mehrere Ebenen sind kein Probleme, außer die Tabellen sind so groß, und wenn Du das mit den Angaben so lösen kannst, wie ich geschrieben habe, dann bleiben die Tabellen sehr viel kleiner, und Du brauchst auch weniger joins. Das gleiche gilt für die Inserts, und wenn Du mal 20 Inserts auf der Adminstrations/Eingabeseite brauchst, ist das kein Problem, problematisch wird es erst auf Userseite, weil da die Zugriffszahlen meistens so um den Faktor 100 höher liegen - da ist dann ein Insert zuviel so schlecht wie 100 auf Adminseite.
Für die Daten-Konsistenz: Du mußt vor allem beim Löschen aufpassen, daß Du nicht lauter "Karteileichen" in verknüpften Tabellen bekommst. Da MySQL keine Trigger hat, kannst Du entweder
a) manuell Funktionen zum Löschen eines Datensatzes für jede Tabelle schreiben, und sehr gewissenhaft sein ;-)
b) Dir irgendwo in einer Settingsdatei für alle Tabellen Variablen mit den Verknüpfungen zu anderen Tabellen definieren, ich mache das z.B. so ähnlich:
$parent["articles"]="article_groups";
$children["articles"]=array("article_varianttypes", "article_pricelevels");
So kann man z.B. 1:n Verknüpfungen definieren, bei m:n ists ein bißchen komplizierter. Aber dann reicht eine einzige Funktion, um einen Datensatz einer beliebigen Tabelle unter Beibehaltung der ref. Integrität zu löschen, Du übergibst der Funktion die Tabelle und ID, sie schaut nach den Verknüpfungen, und ruft sich dann rekursiv selbst wieder auf, wenn Verknüpfungen existieren (damit auch Datensätze, die mit Datensätzen verknüpft sind, die mit... usw. gelöscht werden).
Transaktionen halte ich für nicht so dringend, wenn der MySQL-Server stabil läuft, sicherer und besser ist es auf lange Sicht natürlich.
Viele Grüße
Stephan