nicht angemeldet
Hallo Sven,
Mit anderen Worten: Du hast derzeit eine Tabelle mit den Artikeln, und je Artikelgruppe (Schrauben, Milch, Kekse, Autos) dann eine Tabelle, in der einzelne Spalten enthalten sind, welche die angebbaren Eigenschaften des Artikels beschreiben.
Ungünstiges DB-Design, würde ich mal sagen. Jedenfalls vom Standpunkt der Normalisierung aus gesehen.
Ja, darum suche ich ja eine andere Lösung. Die obige existiert zum Glück erst auf dem Papier.
Zunächst mal die Frage: Warum brauchst du für die einzelnen Artikel derartig unterschiedliche Eigenschaften? Ließen sich die Eigenschaften nicht in ein gemeinsames Schema pressen, welches dann für alle Artikel paßt? Im Zweifelsfall kommen also Gewicht/Volumen, Farbe, Abmessungen und Hersteller in eine Tabelle, und Zusatzangaben in ein Textfeld.
Das ist ungünstig, da nach den Eigenschaften auch gesucht werden soll und auch Artikel innerhalb ihrer Gruppe unterschiedlich viele Eigenschaften des glechen Typs haben können. So habe ich es bisher gemacht und das Ganze exploiert bald im Pflegeaufwand.
Oder du legst insgesamt drei Tabellen an, die flexibel zusammengesetzt werden:
- Der Artikel an sich (mit einer Artikel-ID).
- Eine Tabelle mit Eigenschaften und Eigenschafts-ID: Menge, Farbe, Gewinde, Fettgehalt, ...
- Eine Tabelle, die aus drei Spalten besteht: Artikel-ID, Eigenschafts-ID, und Wert.
Damit kannst du dann alle Eigenschaften aller Artikel in genau einer Tabelle verwalten. Die Suche nach Eigenschaften gestaltet sich dann auch recht einfach. Wenn du beispielsweise alle Artikel mit Gewindemaß suchst, findest du die Eigenschafts-ID durch Benutzerangabe heraus, suchst dann alle Artikel-IDs in der Wertetabelle und verknüpfst dann die Artikel-Tabelle damit - und ggf. dann nochmal die Wertetabelle, um alle Angaben zum Artikel zu erhalten.
Ja, das hört sich sehr gut an. Ich habe schon darüber nachgedacht, pro _Datentyp_ eine Tabelle anzulegen und die in den Join mit einzubeziehen. Dann wären auch die Probleme mit Rechnen(Zahlen), Datum, Blobs, Links, etc. verschwunden
Wobei man dann wahrscheinlich genau nach dem Verarbeitungstyp und dem Anzeigetyp einer Eigenschaft unterscheiden muss. Ein Link ist ja nur ein Text, wird eben nur anders angezeigt, als eine normale Zeichenfolge und beinhaltet eine Event-Funktion.
Zahlen sollen rechtsbündig (bzw. dezimalbündig) gezeigt werden, man soll damit rechnen können (habe noch nie probiert, ob bei MySQL SUM auch über Textfelder funktioniert)
na usw.
Die Pflege solche einer Tabelle ist wahrscheinlich etwas aufwendiger, aber auch wesentlich dynamischer. Denn wenn du neue Eigenschaften für bislang unbekannte Artikel hinzufügen willst, kommen die einfach in die Eigenschaftstabelle hinein und können dann sofort einem Artikel zugeordnet werden.
Ja, und wenn das Datentypproblem nicht wäre, dann könnte man auch den Artikel mit _einer_ Abfrage über alle Eigenschaften aufbauen.
Und du kannst, um die Eigenschaften je nach Warengruppe einzuschränken, bzw. zuzuordnen, dann noch eine vierte Tabelle eröffnen, die Einträge hat in der Form "Warengruppe-ID <-> Eigenschafts-ID", damit gewisse Eigenschaften bei einer Warengruppe auftauchen, und der ganze Rest nicht (beispielsweise ist das verwendete Getriebeöl bei Food-Produkten eher uninteressant).
Ja, das wäre dann die Klassendefinitionstabelle für die Warengruppen, in der auch die Anzeigefunktionen, die Validierungsfunktionen usw. für die Eigensschaften stehen. Sowas ähnliches habe ich bisher schon. Funktioniert sogar _sehr_ gut.
Vielleicht gibts noch eine zweite Meinung in diesem Forum.
Das sollte mich freuen. Bisher habe ich aber tiefgründigere "Denkschriften" fast nur von Dir erhalten. Die haben dann aber so nach und nach immer zum Erfolg geführt.
Schaun wir also mal.
Grüße aus dem mittleren Norden
Tom