nicht angemeldet
Sinnvolle Abbildung / Datenbankkonzeption
TSMoin,
ich habe zur Zeit eine Projekt auf dem Tisch wo ich eine beliebige Anzahl Attribute zu einem Artikel und/oder Kategorie erfassen und logischweise auch irgendwann ausgeben muß. Als Sprache setzte ich PHP, als DB MySQL ein.
So, und jetzt nochmal mehr im Klartext: Es handelt sich um eine Art Anzeigenmarkt, dieser soll eine bleibige Anzahl Kategorien und Subkategorien (und eventell Sub-Sub-Sub usw. haben), dieses bilde ich innerhalb der DB als Baumstruktur ab (Neestet-Set).
Soweit, sogut.
Jetzt sollen aber die Produkte innerhalb der Kategorien diverse Attribute haben, manche davon nur einen Wert (BOOL), manche aber auch 2 oder mehrere. Hierbei ist die Art der Werte auch unterschiedlich (Dezimal,Char usw.).
Die Attribute variieren je nach Produktgattung (Kategorien).
Meine Frage an euch ist, wie würdet Ihr das in der DB abbilden?
Ich bin schon soweit das in der "Magento"-Methode zu machen, sprich wirklich in der DB entsprechende Spalten zu erzeugen, was aber schnell an die Grenzen des Systems kommt (mehr als 64 Keys mag MySQL nicht so wirklich).
Also mein Aufruf an euch: Wie würdet Ihr das Problem lösen, was ist der sinnvollste Ansatz?
Gruss Dieter
-
Meine Frage an euch ist, wie würdet Ihr das in der DB abbilden?
Separate Tabelle mit je einem Attribut pro Eintrag.
Hierbei ist die Art der Werte auch unterschiedlich (Dezimal,Char usw.).
Entweder mehrere Tabellen, je eine pro Datentyp. Oder eine Tabelle und darin alles als String speichern. bool als "0" und "1", Zahlen als Stringrepräsentation usw. Je nachdem wie es dir zur Verarbeitung reinpasst. Oder eine Tabelle mit einer Spalte varchar, einer int, einer float... falls das passt. Hängt schwer von dem ab was du mit den Daten anstellen willst.
-
Hallo und guten Morgen,
Oder eine Tabelle und darin alles als String speichern. bool als "0" und "1", Zahlen als Stringrepräsentation usw.
Das ist eine Sackgasse. Das habe ich schon mal durch.
Da muss man dann zuviele Sonderregeln erfinden und programmieren, wenn man nach Attributwerten sortieren, suchen, filtern will. Das fängt schon bei einer vernünftigen Darstellung der Werte im View an.Besser auf Typen runterbrechen. Das stellt zwar das Konzept von relationalen Datenbanken in Frage, aber was soll's?
Grüße
TS
-
-
Tach!
Jetzt sollen aber die Produkte innerhalb der Kategorien diverse Attribute haben, manche davon nur einen Wert (BOOL), manche aber auch 2 oder mehrere. Hierbei ist die Art der Werte auch unterschiedlich (Dezimal,Char usw.). Die Attribute variieren je nach Produktgattung (Kategorien).
Meine Frage an euch ist, wie würdet Ihr das in der DB abbilden?
Du willst vermutlich die Produkte nicht einfach nur beschreiben - das ginge auch mit einem serialisierten Array oder ähnlichem - sondern du willst anzunehmenderweise auch nach diesen Werten suchen. Dann muss man sie auf einfache Weise durchsuchbar ablegen.
Ich bin schon soweit das in der "Magento"-Methode zu machen, sprich wirklich in der DB entsprechende Spalten zu erzeugen, was aber schnell an die Grenzen des Systems kommt (mehr als 64 Keys mag MySQL nicht so wirklich).
Welches Magento meinst du? Das was mir zu dem Namen einfällt ist ein Shop-System und das verwendet das EAV-Model, so wie es encoder in seiner Antwort beschreibt. Spalten bis zum Umfallen jedenfalls sind nur sehr schwer handhabbar - abgesehen von deren begrenzen Anzahl.
dedlfix.
-
Korrekt, ich meinte das EAV von dem Shopsystem Magento.
Das Problem was aber bei dieser Lösung akut besteht (und das auch bei dem Shopsystem) ist, das eine sinnvolle Verwendung - und das beinhaltet auch die Realisation von Cache-Techniken - (temporäre) Hilfstabellen zur besseren Indezierung angelegt werden; und hierbei die einzelnen Attribute als Key definiert werden - da ist bei 64 Schlüsseln pro Tabelle schluss.
Zumal ich mich frage, ob es nicht eine "bessere" Lösung gibt.
Meine große Befürchtung ist das ich halt nachher extrem viele große Querys habe und ich nicht weiß, bedingt durch die unbekannte Produktivumgebung, ob ich Views nutzen kann.
Nun ja, wenns keinen anderen Denkansatz gibt, werde ich wohl zwangsweise das eav nehmen müssen.
VG Dieter
-
Moin!
Meine große Befürchtung ist das ich halt nachher extrem viele große Querys habe und ich nicht weiß, bedingt durch die unbekannte Produktivumgebung, ob ich Views nutzen kann.
Nun ja. NoSQL wurde Dir ja schon vorgeschlagen. Zur "unbekannten Produktivumgebung":
Derlei geht immer in die Hose, wenn die Anforderungen extrem werden. In solchen Fällen kann man eben nicht mit einem "kleinsten gemeinsamen Nenner" herumbasteln, sondern muss die Möglichkeiten aktueller Software auch ausschöpfen. Das bedeutet dann auch mal die klare Ansage: MySQL ab 5.6, weil es ab da NoSQL kann. PHP? Nicht unter 5.5. wg. opcache ...
So wie Du das darstellst geht es nämlich um ein viel genutztes Anzeigesystem mit Millionen von Anzeigen und Abrufen, welches im Massenhosting ohnehin nicht zu betreiben ist. Da braucht es eh (mindestens) einen eigenen Server und genau dann kann man solche Anforderungen auch stellen.
Jörg Reinholz
-
-
-
Also mein Aufruf an euch: Wie würdet Ihr das Problem lösen, was ist der sinnvollste Ansatz?
Moin Moin,
ich würde mir mal Dokumentenorientierte Datenbanken ansehen. Ob Key-Value-Datenbanken oder Spaltenorientierte Datenbanken, eventuell auch eine Alternative sind, hängt von den genauen Anforderungen ab.