Produktdatenbank - Wie Designen ? :)

devJens

devJens

Benutzer
Beiträge
5
Hallo alle zusammen,

derzeit stecke ich in den Anfängen von einem privaten Projekt. Dabei will ich versuchen eine Produktdatenbank für Hardware aufzubauen, später soll dann ein Spring Boot REST Backend folgen und sofern ich das schaffen sollte so möchte ich mich an ein Angular Front End wagen welches als Preisvergleich umgesetzt werden soll. Wichtig ist mit dabei zu erlernen wie mit extrem vielen Produkteigenschaften umzugehen ist.

Grundkenntnisse sind da, bin Student der Informatik, ca. 2/3 der Scheine sind gemacht.

Warum das ganze: Besseres Verständnis für Datenbanken entwickeln, persönliches Interesse.

Mein aktueller Stand ist der Versuch ein Datenbank Schema für das Produkt "CPU" zu gestalten. Mein Ziel ist es das meiste an Hardware abzudecken was auch bei Geizhals zu finden ist, also auch z.B.: Mainboards, GPUs, RAM, usw.

Hier ist die CPU Übersicht Seite:
AMD mit CPU-Serie AMD: Ryzen 3000, Sockel: AM4 Preisvergleich Geizhals Deutschland
Hier ist eine CPU Detail Seite:
AMD Ryzen 3 3200G, 4C/4T, 3.60-4.00GHz, boxed ab € 89,00 (2020) | Preisvergleich Geizhals Deutschland

Dabei sind folgende Produktinfos ersichtlich:

Segment:
Chipsatzeignung:
Architektur:
Codename:
CPU-Familie AMD:
CPU-Serie AMD:
CPU-Suffix AMD:
Sockel:
Kerne:
Threads:
Basistakt:
Turbotakt:
SMT:
Freier Multiplikator:
Fertigungsprozess:
TDP:
L2-Cache:
L2-Cache-Detail:
L3-Cache:
L3-Cache-Detial:
Chipsatz-Interface:
PCIe 3.0 Lanes:
PCIe 3.0 Lanes Details:
Systemeignung:
Speicher max.:
Speicherbandbreite:
Speichercontroller:
ECC-Unterstützung:
Speichertakt:
Grafik (iGPU vorhanden):
iGPU-Einheiten:
iGPU-Shader:
iGPU-Takt:
iGPU-Interface:
iGPU-Rechenleistung:
iGPU-Funktionen:
CPU-Funktionen:
Heatspreader-Kontaktmittel:
Temperatur max.:
Verpackung:
Kühler:
Stepping:
CPU-Funktionen:
Fernwartung:
Systemeignung (Anzahl Sockel):
Einführung:
Herstellergarantie:
Hersteller-Link:
Letztes Preisupdate:
Veröffentlichung:
Gelistet seit:


Bei der Recherche im Internet auf folgende interessanten Infos gestoßen (falls es andere Interessiert sind)...

Database Schema for Multiple Types of Products

Database schema

What is an efficient design to store variables for different product lines in ER database?

Entity–attribute–value model - Wikipedia


How are product attributes and attribute options stored in Magento database?


So und nun zur eigentlichen Frage. In Anbetracht das Geizhals viele tausende Produkte in ihrer Datenbank haben, stellt sich die Frage nach einem möglichen Design welches dort wahrscheinlich verwendet wird, bzw. andere eCommerce Plattformen für etwas größere Produktdatenbanken verwenden.

Konkret wäre mein Ansatz nicht EAV zu verwenden, aus Performance gründen sowie der Komplexität, wie gesagt ich habe davon nicht wirklich viel Ahnung, daher gründet die Entscheidung wahrscheinlich eher auf Unkenntnis :D

Beispiel Schema:

Bildschirmfoto 2020-09-23 um 19.32.18.png


Hier ist der Versuch spezifischen Daten für eine Entität in Form einer Komponentenart über Untertabellen zu repräsentieren. Wie der vorherigen Liste zu entnehmen sind wären dies wahrscheinlich einige, am Beispiel oben mit "manufactor" und "cpu_functions" zu sehen. "gpu" und "mainboard" hätten eigene Untertabellen für ihre spez. Eigenschaften. Mögliche gleiche Tabellen für die Komponenten wären evtl. eine Tabelle in der Bilder gespeichert werden.

Bei "manufactor" gibt es nur eine Möglichkeit, bei "cpu_functions" dagegen können mehrere oder keine vorhanden sein, z.B. "AVX", "AVX2" oder "AES (2x FMA)". In der Tabelle "cpu_functions" wären alle Möglichkeiten vorhanden und die Tabelle wäre auch erweiterbar falls später mal neue CPU Funktionen dazu kommen.

Macht das so grundlegend Sinn oder sind große Produktdatenbanken vom Grundschema deutlich anders aufgebaut ? Wenn jemand Literatur, Threads oder sonstige Quellen kennt welche auf solche Fragen abzielt kann er die gerne posten, bin auch dafür Dankbar :)
 
Werbung:
Da hast Du Dir ja was schönes zum Lernen ausgesucht!

Kurze Antwort: Dein Modell ist wahrscheinlich zu spezifisch.
Bspw. gibt es CPU mit embedded GPU oder nicht (und wie man mittlerweile weiß, auch CPU mit embedded CPU (Pro Kern), aber warum gibt es keine GPU Funktionen und was ist mit ARM Prozessoren, IO Pins, Raspberry Boards, DSP Signal Prozessoren usw. usf.
Allgemeiner: Die Eigenschaften die man z.B. auf Geizhals sieht, sind ja immer nur ein Kompromiss zwischen den wirklichen Eigenschaften und denen, die einen Käufer interessieren könnten. Da gibt es dann so lästige Sachen wie Fortschritt, Moden usw. und am Ende will man natürlich Fortschritt, ohne neue Tabellen anlegen zu müssen.

Ich habe ehrlich gesagt keinen Deiner Links gelesen. Mein Ansatz wäre eher in die Richtung, die benötigte oder gewünschte Visualisierung unter die Lupe zu nehmen und zu versuchen, dafür ein Modell zu bauen, nicht für (spezifische) Produkte und ihr inneres Wesen. Dabei kommt man zu ein paar verschiedenen Konstrukten:
- Standalone Merkmale (z.B. embedded GPU), die man einfach irgendwo (relativ bequem) als Array aufführen kann
- geordnete Merkmale, wie z.B. Baureihe, Kerne, die ebenfalls noch in ein Array passen, aber geordnet sein sollten (Alter, Performance, (gedachter zumindest mal) Preis, also Wert/Kosten,..). Hier hat man u.U. eine natürliche Sortierung, alphanumerisch oder eine, die explizit durch Reihenfolge der Angabe oder sogar Sortierkriterium angeben muss.
- aggregierte Merkmale wie z.B. Anzahl Shader, Cachegrößen, .. die mit Min/Max Angaben gefiltert werden könnten (Bei denen man sich fragen darf, gibt man die explizit an und lässt das System aggregieren oder wählt man (aktuelle, marktgängige) selbstdefinierte Cluster mit Min/Max Größenangaben
- Widerspruchs Definitionen, die je nach gewünschter Visualisierung vermeiden, sich ausschließende Merkmale anzukreuzen (nicht immer passen die in ein Merkmalsarray
...
Ein paar Dinge, die sich sehr wohl zusammen fassen lassen:
- Maße
- Gewichte
- Anzahl
- Einheiten generell
...
Kategorien (Überschriften) mit Gruppierung
Eine Leiterbahnbreite gibt es für CPU und GPU, einen "Fertigungsprozess" gibt es aber für alles mögliche

Umsetzung:
- eine Mischung aus ein paar modellierten Tabellen und HStore oder JSON(B) Konstrukten (mit Indizierung)

Vorgehen:
Für Deinen Produktausschnitt (CPU/GPU) ein minimalistisches Modell entwerfen, inkl. Internationalisierung und so lange Abspecken, wie kein Informationsverlust entsteht und kein sehr offensichtliches Performanceproblem zu erwarten ist und keine oder nur minimale, Prinzip bedingte Denormalisierungseffekte auftreten und diese konstruktiv überwacht werden können.

Prüfung, ob eine gewünschte Visualisierung möglich ist, inkl. Bedienung, filtern usw.

Prüfung II / Iterationsschritt: Produktpalette erweitern und den Impakt auf das entworfene Modell bestimmen.
Die Iterationen kannst Du dann so oft machen, wie Du willst, bis Du bei Äpfel und Birnen gelandet bist. Wenn die auch passen, wäre es top, denn Äpfel und Birnen kann man bekanntlich nicht vergleichen.

Achso, es gibt bei Geizhals ein paar lustige kleine Effekte, die man entdeckt, wenn man Artikel mit möglichst umfangreichen Merkmalen filtert. Hatte ich neulich bei Notebooks. Vielleicht kann man die analysieren und das Modellierungsproblem gleich mit lösen.
 
Zuletzt bearbeitet:
ach und noch was
Die Frage ist ja immer, wem das Ganze helfen soll und es wäre sicher naiv, hier nur den Endanwender zu sehen.
Nimm ein Produkt mit irgendeinem Allerweltsmerkmal und gib ihm einen geschützten Namen (oder sogar ein Patent, die Amis können das z.B. gut), wie filterterst Du sowas? Klickst Du z.B. auf Fertigungsprozess 7nm, ist Deine Liste an CPU nur noch halb so lang. Alle Intel Chips fliegen raus. Intel könnte heulen, aber so ist es halt und da gibt es keine Diskussion. An anderer Stelle ist das vielleicht nicht so offensichtlich und die gern vermutete Unabhängigkeit solcher Such- und Vergleichsportale ist einfach nicht so gegeben, wie der Endanwender es gerne glauben möchte. Auch sowas muss man vielleicht modellieren/ berücksichtigen, Funktionen die man "nicht sieht". Ist ein Merkmal "nicht existent", gibt es ein "Synonym", ist seine Existenz "unbekannt" oder wirklich "nicht vorhanden", ..?
 
devJens schrieb:
spezifischen Daten für eine Entität in Form einer Komponentenart über Untertabellen zu repräsentieren. Wie der vorherigen Liste zu entnehmen sind wären dies wahrscheinlich einige,
Zum Vergrößern anklicken....

Davon würde ich absolut abraten. Dinge wie HSTORE oder JSON(B) existieren, damit ist man flexibel. Passende Datentypen verwenden, EAN z.B. nicht als VARCHAR, sondern direkt als EAN-Datentyp. Spart Platz und die DB kann die Konsistenz garantieren.
 
Sehe ich ähnlich wie akretschmer.

In Postgres würde ich auf jeden Fall die dynamischen Attribute in eine JSONB Spalte packen.

Der Screenshot (und die Erwähnung von Magento) lässt aber vermuten, dass Du MySQL verwendest. In MySQL kann man aber letztendlich JSON Spalten nicht indizieren. Dort gibt es nur die Möglichkeit, für jedes Attribut eine berechnete Spalte einzuführen und diese dann zu indizieren - was zu einer Explosion von Indizes und Spalten führen würde - nicht sehr effizient. Deswegen kannst Du den JSON Ansatz dort vermutlich gleich vergessen (oder Du machst ein Upgrade auf Postgres ;) )
 
Vielen herzlichen Dank für eure Antworten :)

Was mir aktuell am meisten bringen würde wäre wahrscheinlich zum einen eine Umsetzung mit PostgreSQL unter der Verwendung von JSON für die dynamischen Attribute (wie ihr das empfohlen habt). Zum anderen ist bei mir leider auch das Interesse an EAV mit MySQL geweckt, so wie es in Magento zum Einsatz kommt.

PostgreSQL + JSON(B) wurde von euch allen ausdrücklich empfohlen, hierfür nochmals vielen Dank.

Somit werde ich als nächstes, wie es @dabadepdu empfohlen hat versuchen strukturiert über mehrere iterationen ein möglichst allgemein gültiges Modell zu entwickeln (für Birnen und CPUs) und weil ich's geil find probier ich das einfach mal für beide Ansätze EAV MySQL sowie PostgreSQL JSON(B).

Sofern das so klappen sollte steht danach die Internationalisierung an, das stelle ich mir auch noch spaßig vor.

Achso hier noch ein kleines Bild von meinem Versuch heute morgen erstmal zu verstehen wie EAV funktioniert (Interessiert die meisten mit Sicherheit eher weniger, aber ich poste es mal für die Nachwelt rein, vielleicht kommt ja noch der ein oder andere Studie vorbei - Fehler inklusive :) )

Bildschirmfoto 2020-09-24 um 15.15.51.png
 
Zuletzt bearbeitet:
Sooo, nach einer ersten Übersicht von EAV Support (grad keine Lust mich da weiter einzulesen) durch Hibernate ist das Ziel "MySQL mit EAV" freudig ausgeschlossen worden. Darauf folgte eine etwas längere suche nach einem gescheiten Modellierungstool für PostgreSQL das mir die gleichen Dienste wie MySQL Workbench erweisen sollte und kostenlos ist. Für jene die da noch nix für kleine private Projekte gefunden haben hier eine kleine Empfehlung SqlDBM - Online Database Modeler.

Erster Zwischenstand...

Bildschirmfoto 2020-09-24 um 21.33.52.png
 
DBeaver ist schon ziemlich gut für's Geld ;). Obwohl ich bei der Modellierung neulich mal etwas enttäuscht war, dass er sich kein Layout merken kann und es etwas beschnitten druckt oder exportiert, weiß nicht mehr genau. Ich benutze solche Tools normalerweise nicht, wollte nur ein schönes Bild, hab aber auch nicht die aktuellste Version installiert.

Was das gezeigte Bild (Modell) angeht:
Die Translationlösung finde ich zu aufwändig. Damit brauchst Du für jede Tabelle noch mal eine Translationtabelle. Mein Ansatz wäre eher, die Tabellen "normal" zu designen (einsprachig) und den Text dort (in genau einer Sprache) als "Basissprache" zu betrachten, ein "Rohinhalt". Die Translation kommt dann über einen Foreign Key, die verwendete Sprache über eine (Session)Variable, Funktion o.ä. ... gerade mit PG müsste das ganz gut machbar sein*, über einen Client kann die Variable natürlich auch eingespeist werden. Dabei kann man sogar unterscheiden, ob man Endkundensprache möchte oder Anwendersprache. Das eine beträfe die Internationalisierung der Nutzdatenausgabe, das andere die Internationalisierung der Benutzerschnittstelle. (Meine 5 Cent)
An der Stelle kann vielleicht auch angenehm mit Views arbeiten, mit denen man ein Interface z.B. über die Translation legt und nur noch mit internationalisierten "Tabellen" arbeitet.*
Ansonsten mal nach gängigen Internationalsierungsmodellen / -Verfahren im Netz schauen.

* Die Handhabung von Views und Variablen läuft je nach Verwendung (Fat Client / Web, also Statefull/ Stateless) etwas anders. Am besten geht es Statefull, vielleicht sogar mit den neuen Schema Variables in PG 13.
 
Nach einiger rescherche zu möglichen Designs einer Internationalisierung / Lokalisierung denke ich das ich grundlegend bei dem zuvor gezeigtem Design erstmal bleibe, hier jedoch default parameter (wie zuvor empfohlen wurde :) ) mit in die Ausgangstabelle aufnehme und dann alle weiteren Sprachen über eine weitere Tabelle darstelle.

Diverse Seiten auf welchen das Thema Internationalisierung behandelt wurde...

Database Internationalization(I18N)/Localization(L10N) design patterns

Schema for a multilanguage database (etwas weiter runter scrollen, method 3 / 5)

Creating Multilingual Websites - Part 2

Tutorials - Multilanguage Database Design In Mysql | ApPHP - Professional PHP Web Scripts

Database modeling for international and multilingual purposes

Aktuell gibts noch viele Fragezeichen, bin mir ziemlich unsicher was das Design angeht. In Anbetracht der Produkte welche nicht für alle Märkte bereit stehen, die Zulieferer welche das Produkt auf keinem, einen oder diversen märkten mit verschiedenen Währungen usw. vertreiben können...

Nice wäre es auch eine Produkthistorie zu haben und auch eine Rating Funktion für die Produkte, erster versuch ist auch dabei.


Bin natürlich noch nicht fertig, hier jedoch der aktuelle Zwischenstand, bin nach wie vor für Anregung sehr offen und nochmals ganz vielen lieben Dank für die Hilfe :)


Bildschirmfoto 2020-09-26 um 18.58.09.png
 
Du bist Dir noch unsicher?
Ja, wieso nicht?
Irgendwann muss halt mal "Fleisch an die Knochen". Du wirst beim Programmieren und beim Ausprobieren Deiner Anwendung sehen, wo Du die größten Bauchschmerzen bekommst. Da es hier nicht um eine Wetterstation geht und eine hinreichende (,mögliche) Komplexität vorliegt, wird es kein "bestes" Modell geben. Wenn Du morgen mit der Umsetzung anfängt, wird auch nicht 2h später die Datenmodell Polizei bei Dir klingeln.
Neben "nice", gibt es noch ettliche andere Stichpunkte, die man berücksichtigen könnte. Löschen und wenn ja wie, Aktualisieren und wenn ja wie (beides spielt in eine Historisierung rein und neben der will man vielleicht auch eine Futurerisierung- ich glaube zumindest nicht, dass am Blackfriday die Sachbearbeiter bis Donnerstag Mitternacht da sitzen und Produktänderungen eintragen, um dann um Schlag 12 auf den Confirm Button zu drücken), Produktverfügbarkeit /art, bei Hardware nicht so eine große Frage, aber vielleicht bei Software, bei Dienstleistungen, z.B. betreffen Lagerhaltung / on-stock <> undendlich, .. um mal 2-3 zu nennen.

Nach Privatprojekt sieht es eh nicht aus, und wenn Du viele Fragezeichen hast, dann müsstest Du wohl mal konkret eins nennen. Dann kannst Du sicher Tipps bekommen.

Bei einem Datenmodell geht es immer um Normalisierung oder Verletzung der Normalisierung. Wenn das eintritt, sollte es bekannt sein und absichtsvoll geschehen bzw. bewusst. Dann muss es durch absichernden Code begleitet werden, der Duplikate überwacht usw..

Ich persönlich finde es schön, wenn ein Modell und seine Aus-Programmierung eine "gewisse" Vollständigkeit besitzt. Also nicht nur fancy features, sondern vollständig und dann halt feature ärmer-wegen Aufwand. Nicht nur "get brexit done", sondern auch "get it undone", wenn's sein muss. Und das natürlich nicht nur auf Basis einer geplatzten Transaktion, die selbst alles aufräumt-nette Sache-, sondern funktional.
Also kleines Beispiel: Default Text ändern und alle Translations werden "dirty" markiert. Oder auch "Undo Default Text Änderung" und alles ist wieder "clean".
 
Vielen Dank für deine Antwort :)

Bin jetzt bei einem React Frontend mit Redux, Spring Boot REST Backend sowie JWT mit Spring Security. Dafür konnte ich sehr gute tutorials finden und denke das ich mich mit weiterer Lektüre angemessen einarbeiten kann.

Das Datenbankdesign ist nach weiteren Änderungen, abgesehen von einer Sache soweit das ich mit dem REST Backend anfangen möchte. Und nun zur Frage, was würdet Ihr empfehlen um Bilddateien zu speichern, Thumbnails und Produktbilder ? Direkt als blob/bytea in postgreSQL oder unter Verwendung einer externen Lösung durch AWS oder Azure Blob Storage ?

Für AWS müsste ich mir erstmal eine Kreditkarte besorgen :D
 
Werbung:
Zurück
Oben