Datenbank-Design / Viele Anfänger-Fragen bevor es los geht...

christian72

Neuer Benutzer
Beiträge
2
Hallo zusammen,

ich möchte Produktdaten (Fa für Internethandel) in einer MySQL-Datenbank speichern, hab auch schon ein Bisschen was gelesen, bin mir aber noch nicht sicher wie ich damit anfangen soll. Ich hab Fragen zum korrekten Aufbau, den Feldtypen, dem PrimaryKey und den Abhängigkeiten in der MySQL-Datenbank. Ich schreib einfach mal drauf los, und löcher euch mit meinen Fragen.

Mal 2 Tabellen mit denen ich anfangen möchte:

Tabelle1 (Grundlegende Produkt-Daten):

  • art_ean ( BIGINT unsigned 13 digits ? )
  • art_buy_eur ( FLOAT 8,2 ? )
  • art_sell_eur ( FLOAT 8,2 ? )
  • art_ship_eur ( FLOAT 8,2 ? )
  • art_height_cm ( FLOAT 7,1 ? )
  • art_width_cm ( FLOAT 7,1 ? )
  • art_length_cm ( FLOAT 7,1 ? )
  • art_weight_kg ( FLOAT 8,3 ? )
  • art_diameter_cm ( FLOAT 7,1 ? )
  • art_material ( TINYBLOB oder TINYTEXT ? )
  • art_color ( TINYBLOB oder TINYTEXT ? )
Tabelle2 (URL's zu Bildern):
  • pic_1 ( VARCHAR 120 ? )
  • pic_2 ( VARCHAR 120 ? )
  • pic_3 ( VARCHAR 120 ? )
  • usw.
Dann Tabelle 3 für Artikelbeschreibungen teils mit HTML-Formatierungen und in verschiedenen Sprachen (Welcher Feldtyp wäre da der Beste?) und noch einiges mehr... (Zum Erklären reicht das bestimmt.) Ich komme gesamt auf ca. 100 unterschiedliche Felder, die ich in 10 Tabellen zu unterschiedlichen Bereichen aufteilen möchte. Sicher könnte man auch alle Felder in eine einzige Tabelle packen und sich die Beziehungen der Tabellen unter einander sparen, was sind denn dabei die Vorteile und Nachteile? Wann macht's Sinn die Daten auf mehrere Tabellen aufzuteilen?

Anstatt "nur" URL's zu Bildern kann man auch die Bilder selbst in der DB speichern?

Keine Bindestriche sondern Unterstriche in den Feldnamen hab ich gelesen, weil's sonst zu Fehlern kommen kann. Glaub der Bindestrich gilt als Sonderzeichen ja?

Machen die Feldtypen oben soweit Sinn oder kann ich daran was verbessern?


(Keine doppelten Daten, hab auch zu Vermeidung von Redundanz und Normalisierung schon bissl was gelesen.)

Ich hab Artikel zu denen zwar einige Daten da sind, wo aber zB. keine EAN vergeben ist, also kann die EAN kein PrimaryKey sein, weil ich sonst bei Artikeln ohne EAN nix speichern könnte, richtig? Über "Prymary Key auto increment" habe ich gelesen. Für jeden neuen Datensatz gibt's dann eine fortlaufende Nummer? Wenn ich mehrere Tabellen in der DB habe, braucht dann jede Tabelle einen PrimaryKey? Und ist das dann jedes Mal die gleiche ID? Oder gibts den PrimaryKey in jeder Tabelle?

Wenn ich später zB. CSV-Dateien in die Datenbank importieren will, wie kommen die Daten an die richtigen Stellen in der Datenbank? Wenn man Daten abfragt, wie funktioniert die Beziehung, (Relationship?) von einer Zeile in Tabelle1 zu einer Zeile in Tabelle2 ? Das hat dann wieder mit dem PrimaryKey zu tun?

Entschuldigung, dass ich gleich soviele Fragen hab! :rolleyes: Ich möchte halt nicht alles falsch machen, wenn ich damit anfange.

Nu soll's erstmal reichen. :)

Danke für eure Hilfe!

Gruß Christian
 
Werbung:
Hallo zusammen,

ich möchte Produktdaten (Fa für Internethandel) in einer MySQL-Datenbank speichern, hab auch schon ein Bisschen was gelesen, bin mir aber noch nicht sicher wie ich damit anfangen soll. Ich hab Fragen zum korrekten Aufbau, den Feldtypen, dem PrimaryKey und den Abhängigkeiten in der MySQL-Datenbank. Ich schreib einfach mal drauf los, und löcher euch mit meinen Fragen.

Viele Fragen auf einmal. Vorab: mitMySQL ein neues Projekt anzufangen - hast Du Dir mal Alternativen, insbesondere PostgreSQL angeschaut?


Mal 2 Tabellen mit denen ich anfangen möchte:

Tabelle1 (Grundlegende Produkt-Daten):
  • art_ean ( BIGINT unsigned 13 digits ? )
  • art_buy_eur ( FLOAT 8,2 ? )
  • art_sell_eur ( FLOAT 8,2 ? )
  • art_ship_eur ( FLOAT 8,2 ? )
  • art_height_cm ( FLOAT 7,1 ? )
  • art_width_cm ( FLOAT 7,1 ? )
  • art_length_cm ( FLOAT 7,1 ? )
  • art_weight_kg ( FLOAT 8,3 ? )
  • art_diameter_cm ( FLOAT 7,1 ? )
  • art_material ( TINYBLOB oder TINYTEXT ? )
  • art_color ( TINYBLOB oder TINYTEXT ? )

BIGINT für EAN? PostgreSQL hätte hier einen eigenen Datentyp, der auch die Prüfsumme einer EAN prüft.


Tabelle2 (URL's zu Bildern):
  • pic_1 ( VARCHAR 120 ? )
  • pic_2 ( VARCHAR 120 ? )
  • pic_3 ( VARCHAR 120 ? )
  • usw.


usw. Hä? Das klingt nach falschem Design.

Dann Tabelle 3 für Artikelbeschreibungen teils mit HTML-Formatierungen und in verschiedenen Sprachen (Welcher Feldtyp wäre da der Beste?) und noch einiges mehr... (Zum Erklären reicht das bestimmt.) Ich komme gesamt auf ca. 100 unterschiedliche Felder, die ich in 10 Tabellen zu unterschiedlichen Bereichen aufteilen möchte. Sicher könnte man auch alle Felder in eine einzige Tabelle packen und sich die Beziehungen der Tabellen unter einander sparen, was sind denn dabei die Vorteile und Nachteile? Wann macht's Sinn die Daten auf mehrere Tabellen aufzuteilen?

Normalisierung macht immer Sinn.


Anstatt "nur" URL's zu Bildern kann man auch die Bilder selbst in der DB speichern?

Keine Bindestriche sondern Unterstriche in den Feldnamen hab ich gelesen, weil's sonst zu Fehlern kommen kann. Glaub der Bindestrich gilt als Sonderzeichen ja?

Machen die Feldtypen oben soweit Sinn oder kann ich daran was verbessern?


(Keine doppelten Daten, hab auch zu Vermeidung von Redundanz und Normalisierung schon bissl was gelesen.)

Ich hab Artikel zu denen zwar einige Daten da sind, wo aber zB. keine EAN vergeben ist, also kann die EAN kein PrimaryKey sein, weil ich sonst bei Artikeln ohne EAN nix speichern könnte, richtig? Über "Prymary Key auto increment" habe ich gelesen. Für jeden neuen Datensatz gibt's dann eine fortlaufende Nummer? Wenn ich mehrere Tabellen in der DB habe, braucht dann jede Tabelle einen PrimaryKey? Und ist das dann jedes Mal die gleiche ID? Oder gibts den PrimaryKey in jeder Tabelle?

Jede Tabelle sollte einen PK haben. Fremdschlüsselbeziehungen sollten auch als solche in der DB definiert sein. Feldtypen hat MySQL nicht sehr viele, dazu sagte ich ja schon was.


Wenn ich später zB. CSV-Dateien in die Datenbank importieren will, wie kommen die Daten an die richtigen Stellen in der Datenbank? Wenn man Daten abfragt, wie funktioniert die Beziehung, (Relationship?) von einer Zeile in Tabelle1 zu einer Zeile in Tabelle2 ? Das hat dann wieder mit dem PrimaryKey zu tun?




Das waren/sind jetzt eher so Metafragen. Beschäftige Dich mit Joins, verwende gleich richtig expliziete Join-Syntax.


Entschuldigung, dass ich gleich soviele Fragen hab! :rolleyes: Ich möchte halt nicht alles falsch machen, wenn ich damit anfange.

Nu soll's erstmal reichen. :)

Danke für eure Hilfe!

Gruß Christian


Der größte Fehler, den Du machst, ist MySQL. Du wirst sehr bald merken, daß moderne Abfragen wie Window-Funktionen da nicht gehen, daß die Datentypen begrenzt sind und das Check-Constraints in MySQL nicht funktionieren. Mit zunehmenden Datenmengen wirst Du merken, daß die Index-Möglichkeiten arg schlecht sind in MySQL und zur Performance-Analyse ein Explain zwar da ist, dieses aber weitestgehend nutzlos ist.

Ich hab Dich gewarnt.
 
Hallo zusammen, :)

hallo akretschmer und danke für deine Antworten!

Die Datenbank muss online sein nicht lokal, also bei einem Hoster liegen. Ich möchte von jedem Rechner mit Internet auf die DB zugreifen können. Unsere Artikel listen wir auf vielen Marktplätzen und in unterschiedlichen Sprachen. Wo es möglich ist würde ich die Artikeldaten gerne direkt aus der DB per PHP einbinden. 2 Hosting-Pakete hab ich zur Auswahl, wo ich's hinlegen könnte, beide bieten nur MySQL. Nein, ich hab mir erstmal keine Alternativen zu MySQL angesehn, weil ich die für mein Projekt deshalb (leider) eh nicht nutzen kann.

Ich weiß, dass ich gleich sehr viele Fragen gestellt habe, deshalb hab ich auch darauf verzichtet, gleich alle Tabellen zu posten, die mir vorschweben. Ich hab nur 2 Tabellen gepostet, weil das reicht um nach den Beziehungen der Tabellen unter einander zu fragen. (Wenn du möchtest, kann ich auch mal alles posten, was ich mir bislang notiert hab.) Ich komme gesamt auf ca. 100 unterschiedliche Felder, die ich in 10 Tabellen zu unterschiedlichen Bereichen aufteilen möchte. Sicher könnte man auch alle Felder in eine einzige Tabelle packen und sich die Beziehungen der Tabellen unter einander sparen, was sind denn dabei die Vorteile und Nachteile? Wann macht's Sinn die Daten auf mehrere Tabellen aufzuteilen?

- Wie genau funktionieren diese Fremdschlüsselbeziehungen?
- Machen die Feldtypen (MySQL vorausgesetzt) oben soweit Sinn oder kann ich daran was verbessern?
- Kann man anstatt "nur" URL's zu Bildern, auch die Bilder selbst in der DB speichern?

Danke für eure Hilfe!

Gruß Christian
 
Als erstes solltest du dich wirklich mit Normalisierung beschäftigen. Ein fixer Einkaufspreis für ein Produkt? Meist ändern sich solche Preise und mehrere Preise (egal ob EK oder VK) würde ich immer in einer Tabelle halten. Als Datentyp würde ich NUMERIC() bevorzugen.

Das mit den Bildern in Spalten ist genauso quatsch. Ein Eintrag pro Bild mit Fremdschlüssel, befasse dich mit den Grundlagen zu relationalen Datenbanken (Fremdschlüssel und Primärschlüssel sind die Basis).

Bilder kann man auch direkt speichern, da kenne ich mich aber mit den Eigenheiten von MySQL nicht aus. Ich würde aber keine großen Dateien in der DB ablegen.

Für Produktbeschreibungen mit HTML Formatierung bietet sich eventuell ein XML Datentyp an. Der prüft dann auch die Struktur, ich weiß aber auch hier nicht was MySQL so zu bieten hat.
 
Werbung:
Hier mal eine Demo, wie man zu einem Artikel beliebig viele Bilder ablegt. Gleichzeitig mit Verwendung EAN13-Datentyp und Prüfung EAN-Code auf Korrektheit und eine Foreign Key Constraint Violation:

Code:
test=*# create table artikel (id int primary key, ean ean13, name text);
CREATE TABLE
test=*# create table artikel_bilder(id int primary key, artikel_id int references artikel, bild_link text);
CREATE TABLE
test=*# insert into artikel values (1, '978-1-84951-906-9', 'PostgreSQL Administration Cookbook');
INSERT 0 1
test=*# insert into artikel_bilder values (1, 1, 'Link zu Bild 1');
INSERT 0 1
test=*# insert into artikel_bilder values (2, 1, 'Link zu Bild 2');
INSERT 0 1
test=*# insert into artikel values (2, '978-1-84951-906-8', 'PostgreSQL Administration Cookbook');
ERROR:  invalid check digit for EAN13 number: "978-1-84951-906-8", should be 9
LINE 1: insert into artikel values (2, '978-1-84951-906-8', 'Postgre...
  ^
test=*# insert into artikel_bilder values (2, 3, 'Link zu einem Artikelbild, wo es gar kein artikel gibt');
ERROR:  duplicate key value violates unique constraint "artikel_bilder_pkey"
DETAIL:  Key (id)=(2) already exists.
test=*# insert into artikel_bilder values (3, 3, 'Link zu einem Artikelbild, wo es gar kein artikel gibt');
ERROR:  insert or update on table "artikel_bilder" violates foreign key constraint "artikel_bilder_artikel_id_fkey"
DETAIL:  Key (artikel_id)=(3) is not present in table "artikel".
test=*#

Wie man sieht: die DB garantiert daß nur valide EAN-Codes gespeichert werden, daß Primary Keys nicht doppelt vergeben werden und daß es keine Foreign Keys auf nichtexistente PKs gibt.

HTML in der DB zu speichern halte ich für ungut, weil das dann später wirklich schwer wartbar wird. Da kommst besser, die Merkmale zu speichern und dann das HTML dynamisch zu machen.
Zum speichern böte sich EAV-Design an oder aber (im PG) JSONB-Datentyp. Dann könntest Du die ganze Welt der JSON-Funktionen nutzen.


Was ist das für ein Hosting, Massenmarkt (aka shared hosting) oder habt ihr einen dedizierten Server?
 
Zurück
Oben