Planung einer Datenbankstruktur

[Dimenson]

Hallo Leute,

ich plane mal wieder was neues. Und zwar habe ich vor mehere Produkte in meiner Tabelle einzubauen:

produkte
- id
- name
- hersteller
- beschreibung

Dazu möchte ich gerne eine zusätzliche Tabelle nutzen um hier zu kategorisieren:
kategorie
- id
- name
- beschreibung
- ids

Unter Produkte werden es später vllt 1000 Einträge es sich handeln.
Dementsprechend würde eine Kategorie anlegen und in der Spalte ids die Produkt ids hinterlegen als Array (unserialize) ablegen.
Was meint ihr? Ist das eine sinnvolle Struktur? Oder gibt es noch eine sinnvollere und effizientere ?

Danke

 

[sheel]

Was wäre denn mit:

Produkt:
ID
Name
Hersteller
Beschreibung
Kategorie-ID (einzeln, kein Array etc)

Kategorie:
ID
Name
Beschreibung

 

[saftmeister]

Wenn ein Produkt jedoch mehreren Kategorien angehören kann, brauchst du evtl. eine Kreuz-Tabelle. Außerdem gibt es da noch so was wie die Normalisierung von Datenbanken, was z.B. bei Herstellern Sinn macht. Also in etwa so:

Tabelle Produkt:
ID
Name
hersteller_id
Beschreibung

Tabelle Hersteller:
ID
Name

Tabelle Kategorie:
ID
Name
Beschreibung

Tabelle produkt_in_kategorie:
ID
produkt_id
kategorie_id

Wenn du noch sowas wie Lieferanten hast, wäre es widerum wie bei Kategorien sinnvoll, eine Kreuztabelle zu verwenden. Denn es wäre möglich, ein Produkt aus mehreren Lieferquellen zu beziehen. Ein Produkt wäre dann auch nicht direkt funktional abhängig von einem Lieferanten (auch hier wieder Aspekt der Normalisierung).

 

[para_noid]

Ist das eine sinnvolle Struktur?

Absolut nicht. Du solltest es so angehen wie sheel gepostet hat, das entspricht einem logischen Aufbau in einer Datenbank.

In deinem Beispiel müsstest du bei jedem neuen oder gelöschten Produkt oder bei Produkten, deren Kategorie geändert wurde, zusätzlich das Feld ids in der Kategorietabelle ändern - nur wie sollte das gehen? Du hast ausgehend vom Produkt keinerlei Beziehung zur Kategorie. (Klar kannst du bei einer Änderung z.B. über ein Formular den übermittelten Wert für die Kategorie nehmen, den in der DB suchen, das ID-Array deserialisieren, dein neues Produkt reinschreiben/das alte rauslöschen, serialisieren und wieder in die DB schmeißen, aber das macht echt keinen Sinn).

Kurzerklärung zu Beziehungen in Datenbanken:

Produkt n:1 Kategorie

Jedes Produkt hat genau eine Kategorie, aber eine Kategorie kann auf viele Produkte zutreffen. n:1-Beziehungen stellt man dar, indem die Identifizierung der eindeutigen Entität (der Kategorie) der anderen (Produkt) als Fremdschlüssel zugeordnet wird, siehe sheels Vorschlag für die Produkttabelle.
Mögliche Änderungen einer Kategorie kann dann mittels referenzieller Integrität an die Produkttabelle durchgereicht werden; wenn sich z.B. die ID einer Kategorie ändern sollte, ändert sich die KategorieID bei den betreffenden Produkten automatisch (sofern dies für die Tabelle angegeben wurde, aber ich schweife eh langsam ab).

Wenn der Einwand von saftmeister zutrifft haut das natürlich nicht mehr hin (dann haben wir keine n:1-Beziehung mehr); aber diese Fragen müssen vor Erstellung der DB-Struktur eindeutig geklärt sein.

@saftmeister: die Vorgehensweise mit dem Auslagern der Hersteller lässt mich immer so'n bisschen zweifeln. Klar ist es laut Theorie so besser, weil alle Datensätze damit eindeutiger werden; aber macht die Auslagerung in deinen Augen Sinn, wenn es sich nur um eine Spalte (Herstellername) handelt und nicht mehr? Ich bin in solchen Fällen immer geneigt, mir eine Tabelle und damit einen JOIN zu sparen.

 

[Dimenson]

Hallo,

danke für eure Antworten. Die Lösung von Saftmeister gefällt mir ganz gut. Weil halt auch ein Produkt in verschiedenen Kategorien sein kann.

Ich denke ich werde die Hersteller Tabelle dennoch nutzen. So kann eine Navigation mit Herstellern schnell umsetzen und ich denke das der Performanceanspruch mit einem weitern JOIN sich nur geringfügig erhöht. Natürlich ist auch ein Automatismus dahinter, es werden jede Nacht von einer Quelle die Produkte neueingelesen. Und daher können auch die Hersteller dynamisch generiert werden.

Gruß
Dimenson

 

[saftmeister]

@saftmeister: die Vorgehensweise mit dem Auslagern der Hersteller lässt mich immer so'n bisschen zweifeln. Klar ist es laut Theorie so besser, weil alle Datensätze damit eindeutiger werden; aber macht die Auslagerung in deinen Augen Sinn, wenn es sich nur um eine Spalte (Herstellername) handelt und nicht mehr? Ich bin in solchen Fällen immer geneigt, mir eine Tabelle und damit einen JOIN zu sparen.

Da fragst du den falschen, ich bin auch gegen ein aufgeblähtes Datenbankmodell. Ich wollte nur das theoretisch mögliche (und in geneigter Literatur empfohlene) aufzeigen.

Prinzipiell würde ich gerade an dieser Stelle den Hersteller durchaus auslagern. Denn über den Hersteller will ich nicht nur den Namen sondern in der Regel auch Adresse, Telefon, Internet-Auftritt und dergleichen speichern. Dann macht es auf jeden Fall Sinn.

Ein JOIN tut nicht weh, wenn die beteiligten Spalten einen Index haben.