Datenbankplanung dynamische Felder

[lord-spam]

Hallo,

wir sind dabei eine Datenbank zu planen und uns kommt nicht die perfekte Lösung in den Sinn.

In der Datenbank sollen Listen erstellt werden, z.B. für Filme. Nichts wildes. Doch nun das Problem.
Zu jedem Eintrag der Liste soll es Details geben. Um beim Beispiel zu bleiben, ist der Eintrag ein Film, soll es andere Details geben als bei anderen Einträgen.
Doch sollen die Details pro Kategorie dynamisch sein. Es soll die Möglichkeit geben, über das Administrations Werkzeug neue Detail Felder zu erzeugen, die dann für die Kategorie gültig sind. Die zusätzlichen Felder sollen einen Namen (der später zu Anzeige genutzt werden soll) und je nach Detail andere Datentypen bekommen.

Ich hoffe man versteht was ich meine und jemand kann mir auf die Sprünge helfen, oder jemanden fällt ein gutes Beispiel ein, was ich mir anschauen sollte.

Danke im Voraus.

[Christoph]

Eine Lösung im Entity-Relationship-Modell findest Du unter dem Stichwort "weak Entities" und "one-to-many Relationship". Das lässt sich dann nach Lehrbuch übertragen ins relationale Modell.

Schritt für Schritt-Anleitung und Beispiele findest Du hier: http://lionel.kr.hs-niederrhein.de/~...Kap2.4-4up.pdf

[lord-spam]

Das ist zwar nicht das was ich meinte, aber trotzdem danke für das pdf. Das ist eine super Zusammenfassung.
Und ich habe das Problem nun gelöst.

[jan61]

Moin,

...Und ich habe das Problem nun gelöst.

es ist immer nett, wenn Du dann auch kurz beschreibst, wie Du das gelöst hast. Dann haben auch die anderen was davon.

Unabhängig von Deinem (bisher unbekannten) Lösungsansatz: Man macht das oft so, dass man eine 2. Tabelle aufbaut, in der nur drin steht, welche Details zu welcher Kategorie der Haupt-Tabelle gehören können (da das i. d. R. eine m:n-Relation darstellt, löst man die meist noch über eine Tabelle auf, die nur die möglichen Kategorien enthält). Und dann gibt es eine Detail-Tabelle, die genau diese möglichen Details enthält. Beispiel (etwas allgemein gefasst, ich weiß ja nicht, welches DBMS Ihr benutzt):

-- Die Tabelle mit den Kategorien
CREATE TABLE kategorien (
  id_kategorie INT NOT NULL,
  bez_kategorie VARCHAR2(30) NOT NULL
);
CREATE UNIQUE INDEX pk_kategorie ON kategorie (id_kategorie);
INSERT INTO kategorie (id_kategorie, bez_kategorie)
  VALUES (1, 'Film');
INSERT INTO kategorie (id_kategorie, bez_kategorie)
  VALUES (2, 'Buch');
-- die Tabelle mit den moeglichen Details zu einer Kategorie
CREATE TABLE kat_details (
  id_kat_details INT NOT NULL,
  id_kategorie INT NOT NULL,
  bez_detail VARCHAR2(32) NOT NULL
);
CREATE UNIQUE INDEX pk_kat_details ON kat_details (id_kat_details);
CREATE UNIQUE INDEX idx_kat_details_1 ON kat_details (id_kategorie, bez_detail);
INSERT INTO kat_details (id_kat_details, id_kategorie, bez_detail)
  VALUES (1, 1, 'Schauspieler');
INSERT INTO kat_details (id_kat_details, id_kategorie, bez_detail)
  VALUES (2, 1, 'Regisseur');
INSERT INTO kat_details (id_kat_details, id_kategorie, bez_detail)
  VALUES (3, 2, 'ISBN13');
INSERT INTO kat_details (id_kat_details, id_kategorie, bez_detail)
  VALUES (4, 2, 'Autor');
-- die Tabelle mit den Haupt-Eigenschaften
CREATE TABLE liste (
  id_eintrag INT NOT NULL,
  id_kategorie INT NOT NULL,
  bez_eintrag VARCHAR2(128),
  eigenschaft_1 VARCHAR2(64)
);
CREATE UNIQUE INDEX pk_liste ON liste (id_eintrag);
INSERT INTO liste (id_eintrag, id_kategorie, bez_eintrag, eigenschaft_1)
  VALUES (1,1,'Ein toller Film', 'Film-GmbH');
INSERT INTO liste (id_eintrag, id_kategorie, bez_eintrag, eigenschaft_1)
  VALUES (2,1,'Ein blöder Film', 'Schrott-GmbH');
INSERT INTO liste (id_eintrag, id_kategorie, bez_eintrag, eigenschaft_1)
  VALUES (3,2,'Ein tolles Buch', 'Buch-GmbH');
-- die Tabelle, die die Details enthält
CREATE TABLE details (
  id_detail INT NOT NULL,
  id_eintrag INT NOT NULL,
  id_kat_detail INT NOT NULL,
  wert_detail VARCHAR2(255)
);
CREATE UNIQUE INDEX pk_details ON details (id_detail);
CREATE INDEX idx_details_1 ON details (id_eintrag, id_kat_detail);
INSERT INTO details (id_detail, id_eintrag, id_kat_detail, wert_detail)
  VALUES (1, 1, 1, 'der Star');
INSERT INTO details (id_detail, id_eintrag, id_kat_detail, wert_detail)
  VALUES (2, 1, 1, 'noch ein Star');
INSERT INTO details (id_detail, id_eintrag, id_kat_detail, wert_detail)
  VALUES (3, 1, 2, 'Allan Smithee');
INSERT INTO details (id_detail, id_eintrag, id_kat_detail, wert_detail)
  VALUES (4, 2, 2, 'Allan Smithee');
INSERT INTO details (id_detail, id_eintrag, id_kat_detail, wert_detail)
  VALUES (5, 3, 1, '978-1-234-5678-9');
INSERT INTO details (id_detail, id_eintrag, id_kat_detail, wert_detail)
  VALUES (5, 3, 2, 'Stefan König');

Der Nachteil bei solchen Lösungen ist, dass in der Detail-Tabelle für die Spalte "wert_detail" ein Datentyp benutzt werden muss, der allen möglichen Detail-Eigenschaften genügt und nicht per DB-Design solche Sachen wie Eindeutigkeit der Eigenschaft, Wertebereiche usw. geprüft werden können. Das muss dann entweder die Anwendung oder eine SQL-Prozedur o. a. erledigen. Man lässt bei solchen Designs also etliche Möglichkeiten brachliegen, die ein vernünftiges DBMS bietet.

Jan

[lord-spam]

Moin,

mit

Und ich habe das Problem nun gelöst.

habe ich mich falsch ausgedrückt. Eigentlich sollte es heißen: Und ich habe das Problem nun erstmal anders gelöst.

Nun ja, ich habe mir deine Idee angeschaut. So habe ich mir das auch schon vorgestellt, doch leider ist hier, wie du schon sagst der Datentyp ein bisschen doof. Da dachte ich dann immer, es könnte bessere Möglichkeiten geben und ich frage einfach mal die "Profis", die mit Sicherheit auch schon mal vor der Problemstellung standen.
Trotzdem ist diese Lösung schon einmal toll und ich habe bisher auch keine weiteren Fragen. Danke.
Achso, das DBMS, dass genutzt werden soll steht noch nicht fest, wird aber wahrscheinlich MySQL innoDB werden.
Noch aus Interesse, in deinem (sehr hilfreichen) SQL nutzt du den Datentyp VARCHAR2, ich habe den noch nie gehört, in welchem DBMS gibt es den? Ich bin erst 19 Jahre alt und kam daher auch erst mit einer Hand voll DBMSs in Berührung.

[jan61]

Moin,

...
Noch aus Interesse, in deinem (sehr hilfreichen) SQL nutzt du den Datentyp VARCHAR2, ich habe den noch nie gehört, in welchem DBMS gibt es den?...

Das ist Oracle - einfach ein char-Datentyp, bei dem aber die Spaltenlänge variabel (abh. von den gespeicherten Werten) ist, spart Platz. Im Gegensatz zu char-Datentypen fester Länge, bei denen in manchen DBMS (z. B. DB2 IIRC) die Werte mit Leerzeichen auf volle Länge aufgefüllt werden. Gibts in MySQL aber auch.

Jan

P.S.: Viel mehr als eine Handvoll DBMS kenne ich auch nicht und nur mit exakt einer Handvoll davon habe ich mehr oder weniger regelmäßig zu tun (gehabt) ;-)

[Waxolunist]

Wir haben das folgendermaßen gelöst:

Es gibt eine zusätzliche Tabelle, die die Attributdefinitionen enthält, also die Metadaten.

Darin stehen der Tabellenname für die diese zusätzlichen Attribute gelten, der Name, der Typ und sonstige Eigenschaften.
Eine weitere Tabelle enthält den Wert. Diese Tabelle hat Spalten für den Wert jedes Typs.

Ungefähr sieht dies so aus:

table attributes_meta
{
id
string tablename
string attributename
string attributetype
[optional metadata (constraints):
length, max_length, etc
]
}

table attributes_values
{
id
foreign_row_id
attributes_meta_id
string stringvalue
int intvalue
date datevalue
...
}

Der Zugriff ist eher komplex, aber durchaus möglich. Z.B. via Dynamic SQL, aber auch Hibernate kann damit umgehen.

lg, Christian