Struktur für Parent / Child Produkt

[OnDemand]

Hallo zusammen,

hat jemand noch eine bessere Idee für ein Datenbankdesign für Folgendes:

Es gibt Artikel in verschiedenen Eigenschaften und Varianten

zb Hose in XL, rot und XXL grün. Außerdem gibts Computer mit 16 GB RAM 32GB RAM

Aktuell sieht die DB so aus:
In products_properties_combination stehen Daten zur Kombination wie Preis, Bestand, EAN usw (eigentlich die selbe nDaten wie es auch ein nicht-Varianten Produkt hat)

products_properties_combinations_values hält die Kombinationen und deren Möglichkeiten
zb Kombination 1 gibts in
Größe XL mit Farbe rot
Größe L mit Farbe grün

und die anderen beiden jeweils die Namen wie "Größe", " Farbe" sowie deren Werte wie "XL, L, grün, rot"


Hat jemand ne Idee wie man das eleganter lösen kann? Sind mir irgendwie zu viele Abhängigkeiten und Tabellen. Wie verwerflich wäre es wenn man das Keyvalue paar direkt als Key-Value abspeichert also quasi nicht mit Fremdschlüsseln. Dann wäre diese Daten übel doppelt aber irgendwie einfacher

Freu mich auf euren Input!

 

[mrBrown]

Kannst du mal zeigen, was in welcher Tabelle steht, einfach mit zwei Beispielzeilen für jede?

 

[OnDemand]

Ja klar ich versuchs mal, hoffe es reicht so. Wärehd ich das so schreibe, fällt mir auf wie unnötig tabelle products_properties_combinations ist. Das könnte auch einfach die products_tabelle sein. Entweder hat ein Produkt Kombinationen oder nicht

products_properties_combinations
id, sku, preis
1, AB-DE, 8.00
2, FD-12, 158.00

products_properties_combinations_values (müsste eigentlich products_properties_combinations_values _names heißen ist die link tabelle zwishen names und values)
combi_id, name_id, value_id
1, 1, 3
1, 1, 4
2, 2, 1
2, 2, 2

products_properties_values
id, value
1, rot
2, grün
3, XL
4, S

products_properties_names
id, value
1, Größe
2, Farbe

 

[mrBrown]

Das was du beschreibst ist ein simples Entity-Attribute-Value-Model, deine Variante ist auch die klassische relationale Lösung dafür.

Je nachdem was die Datenbank bietet kann man auch anderes nutzen, zB statt products_properties_combinations_values eine Json-Column direkt in products_tabelle, welche alle Kombinationen enthält. (Wurde hier sogar erst vor kurzem angeschnitten...).

 

[LimDul]

Ich stell mal die - meines Erachtens relevante Frage - Was ist das Problem bzw. was ist der Anwendungsfall?

Klar, die Tabellen explodieren und sind, wenn man auf die Datenbank schaut, nicht mehr auf den ersten Blick übersichtlich aus.

Allerdings, ist das Problem? Denn das Dinge "hübsch aussehen" ist für mich kein Anwendungsfall. Und im Idealfall wird es ja durch das Entitäts-Modell in Java entsprechend abstrahiert und auf der DB durch Foreign Keys findet man sich auch zurecht.

Denn "Menge von Tabellen oder Abhänigkeiten" ist für mich erst mal per se kein Problem.
Ich hab in Java lieber 50 Klassen mit kleiner <100 Zeilen Code als 10 Klassen mit 500 Zeilen Code. Es sieht zwar nach vielen Tabellen und Abhängigkeiten aus - aber die bilden ja eine gekapselte in sich konsistente Bedeutung. Die Abhängigkeiten existieren sollten ja nur untereinander exisitieren - nach Außen hingegen wird es ja hoffentlich abstrahiert.

 

[OnDemand]

Danke für euren Input. Dachte gibt eine schlankere Lösung. Mit den Klassen ist das einfach abbildbar ja, aber ob die Daten nun in 3 oder 1 Tabelle wären macht ja von der Datenmenge kaum einen Unterschied. Bleibt daher wie es ist