Datenhaltung - Datenbankstruktur

[Andreas]

Hallo!

Ich überlege gerade, wie ich die folgenden Daten am besten in MySQL Abspeichern kann:

Dabei habe ich 2 Probleme, erstmal das allgemeine Datenbank-Design

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.

Also:

1 Tabelle "Events" // Tabelle enthält Basisangaben zum jeweiligen Event
Tabelle "Kunden" // Basisdaten der jeweiligen Kunden
Tabelle "Artikel" // Basisdaten der jeweiligen Artikel
Tabelle "Kunden_zu_Event" // Verknüpfungstabelle EventID|KundenID
Tabelle "Artikel_zu_Event" // Verknüpfungstabelle EventID|ArtikelID

soweit so gut(oder würdet Ihr das schon anders machen?), aber wie mache ich jetzt die Angaben zu den Artikeln? Problem außerdem, die "Basisdaten der Artikel" in der Tabelle "Artikel", da kann ich ja nicht die möglichen Angaben speichern, da die ja variabel sind, also brauche ich noch eine

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.

Was haltet Ihr davon? Habe bisher noch keine solchen Datenbank-Designs benötigt, würdet Ihr das evtl. anders machen? 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! Hat vielleicht jemand Tipps für mich wie ich das vernünftig mache und worauf ich achten sollte? Wäre jetzt vielleicht der Zeitpunkt gekommen mich mal mit Transaktionen auseinander zu setzen?

Viele Grüße
Andreas

[Cheatah]

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

[Andreas]

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

[Cheatah]

Hi,

Artikel
+- id

diese Tabelle ist sinnfrei. Es reicht diese:

Angaben_zu_Artikel

Ansonsten sieht es auf den ersten Blick gut aus.

So komme ich sehr schnell an sehr viele Datensätze! [...] aber trotzdem, sehr wohl ist mir dabe nicht!

Das ist kein Problem, mach Dir darüber keine Sorgen.

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?

Eine n:m-Beziehung hast Du über Verknüpfungstabellen wie z.B. Kunden_zu_Event oder Artikel_zu_Event.

Und - was bedeutet hier Redundanz? Ich kennen nur redundante Serveranbindungen(was IMHO heißt das der Server über mehr als 1 Leitung angebunden ist)?!

Redundanz bedeutet (kurz gesagt), dass etwas mehrfach vorhanden ist. Das relationale Datenbankmodell dient dazu, Redundanz zu eliminieren - indem eben als Beispiel nicht die Angaben zum Kunden mit jedem einzelnen Artikel mitgeführt werden, hundert mal bei hundert Artikeln dieses Kunden.

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?

Soweit ich es sehe, ja.

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?

Du kannst nicht nur, Du musst. Vor allem kannst Du aber in Kunden_zu_Event auf Event_id=42 referenzieren, auch wenn ein solcher Datensatz in Event nicht existiert. Um dies zu vermeiden, sind Foreign Keys da - leider (noch) nicht bei MySQL.

Es gibt insert-select, mal gucken ob das was bringt!

Eine Art
INSERT INTO tabelle VALUES (1,2,3), (4,5,6), (7,8,9), ...
wäre hilfreicher. Für einen Select brauchst Du die Daten ja schon in der DB, und Du willst sie ja gerade erst hineinschreiben.

Cheatah

[Andreas]

hi!

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 für andere Tabellen einfügen?
Du kannst nicht nur, Du musst.

Nein, das meinte ich nicht. Das ist klar! Ich meine eben doch "Redundanzen" zu schaffen, um das Problem der Inkonsistenz zu vereinfachen!
Beispiel:
Ich habe die Tabelle Angaben, da referenziere ich nicht nur auf dei Artikel_ID und auf die Kunden_ID, sondern auch auf die Event_ID, so dass ich es einfacher habe alle Angaben zu einem Event zu bearbeiten, zu löschen. Halt nur um Fehler in SQL-Statements, denen ich nicht vorgebeugt habe zu begegnen, indem ich einfach alle Angaben lösche, mit event_ID = xyz! Aber eigentlich sollt man gerade das ja nicht machen, oder?

Vor allem kannst Du aber in Kunden_zu_Event auf Event_id=42 referenzieren, auch wenn ein solcher Datensatz in Event nicht existiert. Um dies zu vermeiden, sind Foreign Keys da - leider (noch) nicht bei MySQL.

Aber was könnte ich da machen? Es muß ja einen Grund haben wenn Event 42 nicht mehr exisitiert, und wenn Event 42 gelöscht wird müsssen auch  alle andeen damit zusammenhängenden Datensätze aus anderen Tabellen gelöscht werden, halt manuell, gibt es eigentlich delete... select?

Aber was machen eigentliche Foreign Keys in einem solchen Fall? Also wenn ich jetzt einen Foreign key auf die EventID in der Tabelle Artikel hätte, würden dann alle Datensätze mit entsprechendem Foreign Key mitgelöscht? automatisch?

Es gibt insert-select, mal gucken ob das was bringt!

Eine Art
INSERT INTO tabelle VALUES (1,2,3), (4,5,6), (7,8,9), ...
wäre hilfreicher. Für einen Select brauchst Du die Daten ja schon in der DB, und Du willst sie ja gerade erst hineinschreiben.

Wußte gar nicht das das geht, das ist in der Tat sinnvoller ;-) Nur ein Delete mit Select wäre nicht schlecht, aber das geht IMHO nicht!

Grüße
Andreas

[Michael Schröpl]

Hallo Cheatah,

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...

Transaktionsfähigkeit ist bei mySQL eine Eigenschaft eines Tabellentyps,
nicht der Datenbank an sich.

Es gibt Tabellentypen, die auf Lesezugriffe optimiert sind (sogar solche,
die komplett als Hash-Baum im Hauptspeicher gehalten werden), und andere,
die transaktionsfähig sind (InnoDB, BDB).
Ich habe noch keine transaktionsfähigen Tabellentreiber benötigt, aber
die Feature- und Konzepte-Liste von InnoDB und Oracle 7 liest sich er-
staunlich gleich.

Die ist bei MySQL grundsätzlich ein Problem, da Foreign Keys (bisher)
nicht unterstützt werden.

Auch das ist eine Eigenschaft des Tabellentreibers:
     http://www.mysql.com/doc/en/ANSI_diff_Foreign_Keys.html
InnoDB kann das also schon in mySQL 3.23.44, d. h. seit knapp einem Jahr:
     http://www.mysql.com/doc/en/News-3.23.44.html
(aktuell ist 3.23.52).

Viele Grüße
      Michael

[Andreas]

Hi Michael!

Transaktionsfähigkeit ist bei mySQL eine Eigenschaft eines Tabellentyps,
nicht der Datenbank an sich.

Es gibt Tabellentypen, die auf Lesezugriffe optimiert sind (sogar solche,
die komplett als Hash-Baum im Hauptspeicher gehalten werden), und andere,
die transaktionsfähig sind (InnoDB, BDB).
Ich habe noch keine transaktionsfähigen Tabellentreiber benötigt, aber
die Feature- und Konzepte-Liste von InnoDB und Oracle 7 liest sich er-
staunlich gleich.

Was würdest Du denn für meinen Fall machen? Meinst Du ich brauche keine Transaktionen? Dann muß doch "nur" der Code so geschrieben sein, das erst gar keine Inkonsistenzen entstehen können, oder? Aber leider habe ich davon noch nicht so viel Ahnung.

Die ist bei MySQL grundsätzlich ein Problem, da Foreign Keys (bisher)
nicht unterstützt werden.

Auch das ist eine Eigenschaft des Tabellentreibers:
     http://www.mysql.com/doc/en/ANSI_diff_Foreign_Keys.html
InnoDB kann das also schon in mySQL 3.23.44, d. h. seit knapp einem Jahr:
     http://www.mysql.com/doc/en/News-3.23.44.html
(aktuell ist 3.23.52).

Hm, aber ich habe noch nie verstanden was Foreign-keys wirklich bringen? http://www.mysql.com/doc/en/example-Foreign_keys.html Wenn ich mir dieses Beispiel angucke, was bringt hier der Foreign-key? Dasselbe kann ich doch auch ohne machen, oder?

Grüße
Andreas

[Michael Schröpl]

Hi Andreas,

Transaktionsfähigkeit ist bei mySQL eine Eigenschaft eines Tabellentyps,
nicht der Datenbank an sich.
Was würdest Du denn für meinen Fall machen? Meinst Du ich brauche
keine Transaktionen?

Das kann ich nicht beantworten. Ich habe nicht den gesamten Thread
im Detail gelesen - ich wollte nur Cheatahs Aussagen an dieser Stelle
korrigieren.
Ob Du Transaktionen brauchst oder nicht, das hängt nicht vom Format
Deiner Tabellen ab, sondern von der Art und Weise, in der Du darin
Änderungen vornehmen mußt.
Wenn Du beispielsweise in zwei Tabellen nur 'gleichzeitig' etwas
ändern darfst (also Deine Datenbank inkonsistent wird, wenn Dein
Programm zwischen zwei INSERTs abstürzt, weil dann ein Datensatz auf
irgendwas zeigt, das es nicht gibt), dann solltest Du Transaktionen
in Erwägung ziehen.
Und wenn Datenverlust schlimm ist (beispielsweise, weil Du Bestellun-
gen eines Shops protokollierst), dann erst recht (sonst bekommt der
Kunde seine Ware, Du aber kein Geld ;-).

Die ist bei MySQL grundsätzlich ein Problem, da Foreign Keys
(bisher) nicht unterstützt werden.
InnoDB kann das also schon in mySQL 3.23.44 ...
Hm, aber ich habe noch nie verstanden was Foreign-keys wirklich
bringen?

Konsistenz. Statt in 47 verschiedenen Zugriffsprogrammen immer wieder
zu prüfen, ob der Inhalt der Datenbank in sich stimmig ist, kannst Du
Dich einfach darauf verlassen, weil die Datenbank selbst sich darum
kümmert.
Selbst wenn Du 47 mal die Prüfung korrekt programmiert hast - was ist,
wenn ein Operateur sich per Terminal anmeldet und einen Datensatz
manuell ändert (weil ein Kunde am Telefon ihn dazu nötigt)? Futsch
ist die schöne Konsistenz. Und wie viele von Deinen 47 Programmen dann
noch korrekt laufen, weiß der Himmel.
Constraints machen dumme Tabellen zu intelligenten Tabellen - also
darfst Du mit dümmeren Programmen darauf zugreifen. ;-)

Wenn ich mir dieses Beispiel angucke, was bringt hier der Foreign-
key? Dasselbe kann ich doch auch ohne machen, oder?

Weder mit demselben niedrigen Aufwand noch in derselben hohen Qualität.

Viele Grüße
      Michael

[Frank Jonas]

Hallo,

wenn ich das Problem richtig verstanden habe, ist der Ansatz schon mal richtig.

Event-,Kunden- und Artikel-Tabelle sowie die entspr. m:n-Tabellen. Wenn mehrere Kunden mehrere Artikel mit unterschiedlichen "Angaben zu Artikeln" anbieten, dann wäre es aus meiner sicht sinnvoll, diese Angaben in der Verknüpfungstabelle Kunde-Artikel zu schreiben.
Das wäre dann ein normalisiertes Datenbankmodell.
Jetzt ist die Frage, wie die Daten bereitgestellt werden und was alles damit gemacht werden kann/soll/muss und wie. Davon hängt dann ab, inwieweit Du Dir Gedanken um Performance machen mußt. Wenn beispielsweise ein Kunde aus einem festen Kundenstamm aus einer festen Menge wählen soll, dann mußt Du nur eine Tabelle Kunde-Artikel behandeln. Wenn ein Kunde sich selbst anmelden kann und neue Artikel mitbringt, dann steigt der Aufwand erheblich. Von Bedeutung ist vielleicht auch noch, ob noch andere Tools Zugriff auf die Datenmenge haben, wie die Daten administriert werden sollen (wer z.B. Kunden und Artikel für ein Event zulässt).

Das wär's was mir aus dem Stegreif dazu einfällt.
HTH
Gruß Frank

[Stephan Huber]

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

[Andreas]

Hey!

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

Wie im gleichen Format in der Tabelle? in welcher Tabelle? Entweder ich speichere das direkt bei den Artikeln _oder_ in einer eigenen Tabelle, oder was hast Du gemeint?
XML kann ich leider nicht, würde aber sehr gerne mal einen Einstieg finden, aber leider verstehe ich nicht ganz ob das so viel Sinn hat?!
Eine doppelte Datenhaltung kann nicht wirklich Sinn der Sache sein!
Also Du meinst ich soll die Angaben des jeweiligen Artikel im XML-Format in der Angaben-Tabelle speichern? Wie soll ich dann die Angaben selbst speichern, also die Daten die die Kunden angeben?

"Angaben", dann brauchst du die "Angaben zu Artikel" nicht, und in "Angaben" hast Du nur noch eine Zeile pro Artikel und Kunde.

Ja, aber was habe ich da für Spalten????

Grüße Andreas

[Stephan Huber]

Hallo Andreas,

Wie im gleichen Format in der Tabelle? in welcher Tabelle? Entweder ich speichere das direkt bei den Artikeln _oder_ in einer eigenen Tabelle, oder was hast Du gemeint?

Ok, unverständlich ausgedrückt: Da die Angaben je nach Artikel verschieden sind, dachte ich mir, daß Du wohl kaum nach einer spezifischen Angabe selektieren willst, z.B. zeig mir alle Artikel, die bei Angabe "A" und Kunde "B" "C" stehen haben, sondern Du willst einfach für jeden Kunden nur seine kundenspezifischen Angaben erhalten, wenn Du einen select machst.
Wenn Du nur das willst, brauchst Du nicht jeden "Angabentyp" und jede kundenspezifische "Angabe" als Reihe in eine Tabelle schreiben.
Dann kannst Du die "Angabentypen" (jetzt mal ohne xml) einfach in eine Textspalte in die Artikeltabelle schreiben, z.B. durch "," getrennt, also "A:Größe,B:Preis,C:Farbe", in der "Angaben"-Tabelle steht dann in einer Zeile nur noch die Kundenid, die Artikelid und in einem festgelegten Textformat die Angaben, z.b."A:riesig,C:grün".
Dann kriegst Du mit weniger joins und in vielen Fällen in einer Zeile, was Du brauchst, und mußt nur noch ein bißchen z.B. mit explode() und assoziativen Arrays am Ergebnis rumspielen.
Wie gesagt, daß eignet sich nur, wenn Du niemals eine Abfrage machen willst, die z.B. nach Kriterium A von Artikel B sortieren soll, aber irgendwie hatte ich das Gefühl, daß Du eher für jeden Artikel ein bißchen strukturierte, kundenspezifische Eigenschaften haben willst. (habe ich aus dem Wort "Event" geschlossen, das irgendwo vorkam, vielleicht wäre es besser, Du beschreibst bei sowas in einem Satz noch, wozu die Datenbank dienen soll, dann kann man es sich besser vorstellen)
Wenn das dagegen z.B. eine Ausschreibungsplattform sein soll, dann ist Dein ursprünglicher Entwurf so "richtig", mein Vorschlag wäre dafür nicht geeignet, der ist ein bißchen "geschummelt", aber dafür werden die Abfragen sehr viel einfacher. (Wundert mich sowieso, daß bis jetzt noch kein SQL-Purist auf mich eingeschlagen hat, das erwarte ich mir hier eigentlich schon ;-))

XML kann ich leider nicht, würde aber sehr gerne mal einen Einstieg finden, aber leider verstehe ich nicht ganz ob das so viel Sinn hat?!

War nur ein Beispiel für eine Möglichkeit, Daten strukturiert in einem Datenbankfeld zu speichern.

Viele Grüße
Stephan