Komma separierte Liste oder viele Spalten?

[dario91]

Hallo Experten!

Bei meinem Datenbankdesign komme ich nicht weiter. Folgendermaßen sieht es aus:
Ich habe eine Tabelle 't_object', die eben einige Spalten hat, u.a. auch die Spalte 'properties'. In dieser Spalte properties stehen derzeit mehrere Werte, die von einem Komma getrennt werden, z.B. '5,6,13'. Aufgelöst werden diese Werde dann durch eine Tabelle names 't_object_properties', bei der die id eben den Werten aus der Liste entspricht.

Jetzt habe ich mal gehört, dass man nicht mehrere Werte in einer Spalte haben sollte, also keine von Kommas getrennte Liste. Um das zu umgehen, müsste ich der Tabelle 't_objects' viele neue Spalten hinzufügen und die die Spalte 'properties' entfernen. Die ganzen neuen Spalten würden dann nur einen bool'schen Wert enthalten, der eben angibt, ob diese Eigenschaft vorhanden ist, oder eben nicht.

Meine Frage ist nun, was aus Perfomancegründen die bessere Wahl ist.
1. So wie bisher, mehrere Werte in einer Spalte und diese mit Kommas getrennt. Aufgelöst werden diese Werte durch eine separate Tabelle.
2. Viele zusätzliche Spalten in der Tabelle 't_object'. (Dabei handelt es sich um ca. 30 zusätzliche Spalten, weil es eben ca. 30 verschiedene Eigenschaften gibt, die ein Objekt haben kann, oder nicht.

Was empfiehlt ihr mir?

Liebe Grüße,
Dario

 

[akretschmer]

Meine Frage ist nun, was aus Perfomancegründen die bessere Wahl ist.
1. So wie bisher, mehrere Werte in einer Spalte und diese mit Kommas getrennt. Aufgelöst werden diese Werte durch eine separate Tabelle.
2. Viele zusätzliche Spalten in der Tabelle 't_object'. (Dabei handelt es sich um ca. 30 zusätzliche Spalten, weil es eben ca. 30 verschiedene Eigenschaften gibt, die ein Objekt haben kann, oder nicht.

Was empfiehlt ihr mir?

Liebe Grüße,
Dario

Nach der reinen Lehre keine der beiden Lösungen, sondern eine extra Tabelle, die zu jedem Objekt die Eigenschaften enthält.
Alles andere ist in normalen Datenbanken Murks.

Solltest Du mit PostgreSQL arbeiten, könntest Du aber auch quasi bei Deinem Design bleiben, aber die Eigenschaften dann entweder als HSTORE oder als JSONB ablegen. Das ist ziemlich cool.
Aber Komma-Listen geht gar nicht, und wenn Du viele mögliche Attribute hast, die zudem auch noch zunehmen können, geht das auch mit den Spalten nicht.

 

[dario91]

Nach der reinen Lehre keine der beiden Lösungen, sondern eine extra Tabelle, die zu jedem Objekt die Eigenschaften enthält.
Alles andere ist in normalen Datenbanken Murks.

Solltest Du mit PostgreSQL arbeiten, könntest Du aber auch quasi bei Deinem Design bleiben, aber die Eigenschaften dann entweder als HSTORE oder als JSONB ablegen. Das ist ziemlich cool.
Aber Komma-Listen geht gar nicht, und wenn Du viele mögliche Attribute hast, die zudem auch noch zunehmen können, geht das auch mit den Spalten nicht.

Danke für die schnelle Antwort, akretschmer!

Wie kann ich mir die neue extra Tabelle vorstellen? Für mich klingt das so, als würde ich damit die Tabelle 't_object' einfach nur teilen.

Ich gebe ein Beispiel:
Im Moment habe ich ja die Tabelle 't_object' mit ca 15 Spalten. Die Spalte 'object_id' sei der PRIMARY KEY. Desweieteren existiert die Spalte 'properties', die von ca. 30 einzelnen propertie-Spalten ersetzten werden soll. Und anstatt diese weiteren 30 Spalten hinzuzufügen, soll ich eine extra Tabelle anlegen, in der diese 30 Spalten stehen und eine weitere Spalte 'object_id', die wiederum der PRIMARY KEY sein soll?

(Es handelt sich um eine MySQL Datenbank)

 

[akretschmer]

Danke für die schnelle Antwort, akretschmer!

Wie kann ich mir die neue extra Tabelle vorstellen? Für mich klingt das so, als würde ich damit die Tabelle 't_object' einfach nur teilen.

test=*# create table properties(id int primary key, name text);
CREATE TABLE
Time: 49,555 ms
test=*# insert into properties values (1, 'eigenschaft 1');
INSERT 0 1
Time: 0,574 ms
test=*# insert into properties values (2, 'eigenschaft 2');
INSERT 0 1
Time: 0,168 ms
test=*# create table objekte (id int primary key, name text);
CREATE TABLE
Time: 7,245 ms
test=*# insert into objekte values (1, 'objekt 1');
INSERT 0 1
Time: 0,429 ms
test=*# insert into objekte values (2, 'objekt 2');
INSERT 0 1
Time: 0,170 ms
test=*# create table objekt_prop (id_objekt int references objekte, id_prop int references properties, primary key(id_objekt, id_prop));
CREATE TABLE
Time: 36,589 ms
test=*# insert into objekt_prop values (1,1);
INSERT 0 1
Time: 17,561 ms
test=*# insert into objekt_prop values (2,2);
INSERT 0 1
Time: 0,356 ms

Ich gebe ein Beispiel:

Ich auch. Siehe oben.

(Es handelt sich um eine MySQL Datenbank)

Mein herzliches Beileid.

 

[dario91]

Achsooo. Das wird dann strukturiert, wie ein n zu m Beziehung! Danke! Jetzt habe ich das verstanden.
Wundert mich jetzt im ersten Moment schon ein bisschen, weil es ja eigentlich keine n zu m Beziehung ist. Aber das wird so schon Sinn machen.

Vielen Dank noch mal für diese Hilfe!!

 

[Hony%]

Aufgelöst werden diese Werde dann durch eine Tabelle names 't_object_properties', bei der die id eben den Werten aus der Liste entspricht.

Wundert mich jetzt im ersten Moment schon ein bisschen, weil es ja eigentlich keine n zu m Beziehung ist.

Was denn sonst?

 

[Distrilec]

Magie...