Tabellenstruktur

[weissnix]

Grüß Euch,

ich grüble seit Langem an einer sinnvollen DB-Tabellenstruktur.

Ein Beispiel aus dem Hausbau:
Dachform = Steildach oder Flachdach
Steildach = Satteldach, Walmdach, Mansarddach, usw. (ca. 6 Dachtypen)
Satteldach = symmetrisch, asymmetrisch
Mansarddach = mit Giebel, mit Walm

Konstruktion = Holz oder Beton
Dämmung = ...
Dachdeckung = Dachziegel, Blech, usw.

Jemand baut ein Haus und wählt das Dach.
Er fragt sich also in einige Ebenen hinunter.
Jede dieser Ebenen hat nur winzige Tabellen, die sich nur bedingt zusammenfassen lassen, weil sie andere Attribute haben.

Dachbauteile haben aber eine ganz andere Tabellenstruktur als z. B. Lichtschalter.

Theoretisch würde ich alles in eine Riesentabelle bringen: ca. 200.000 Zeilen und 500 Spalten, wenn ich alle Bauteile in die Zeilen und alle Attribute in die Spalten gebe. Dadurch würden sich aber endlos viele Leerfelder ergeben.
Also fange ich zu normalisieren an und am Ende habe ich 5.000 Tabellen mit teilweise nur 2 Zeilen und 2 Spalten. Ist das wirklich Sinn der Sache?

Ich finde einfach nichts im www über sinnvolle Tabellenstrukturen, wenn sich die Attribute stark unterscheiden.

Danke schon mal für hoffentlich erleuchtende Antworten.

 

[akretschmer]

Grüß Euch,

ich grüble seit Langem an einer sinnvollen DB-Tabellenstruktur.

Ein Beispiel aus dem Hausbau:
Dachform = Steildach oder Flachdach
Steildach = Satteldach, Walmdach, Mansarddach, usw. (ca. 6 Dachtypen)
Satteldach = symmetrisch, asymmetrisch
Mansarddach = mit Giebel, mit Walm

Konstruktion = Holz oder Beton
Dämmung = ...
Dachdeckung = Dachziegel, Blech, usw.

Jemand baut ein Haus und wählt das Dach.
Er fragt sich also in einige Ebenen hinunter.
Jede dieser Ebenen hat nur winzige Tabellen, die sich nur bedingt zusammenfassen lassen, weil sie andere Attribute haben.

Dachbauteile haben aber eine ganz andere Tabellenstruktur als z. B. Lichtschalter.

Theoretisch würde ich alles in eine Riesentabelle bringen: ca. 200.000 Zeilen und 500 Spalten, wenn ich alle Bauteile in die Zeilen und alle Attribute in die Spalten gebe. Dadurch würden sich aber endlos viele Leerfelder ergeben.
Also fange ich zu normalisieren an und am Ende habe ich 5.000 Tabellen mit teilweise nur 2 Zeilen und 2 Spalten. Ist das wirklich Sinn der Sache?

Ich finde einfach nichts im www über sinnvolle Tabellenstrukturen, wenn sich die Attribute stark unterscheiden.

Danke schon mal für hoffentlich erleuchtende Antworten.

Ich versteh Dein Problem ;-)

Die Frage ist: z.B. Steildach, soll/muß die Auswahl gegen die von Dir aufgezählten Dachtypen (Satteldach, Walmdach, Mansarddach, usw.) geprüft werden, oder soll/darf das flexibel sein? Wozu soll zum Schluß die Datenbank dienen, willst Du nach allen 'Satteldach' - Dächern suchen?

Dein Problem klingt a bissl nach NoSQL-Datenbanken, aber da bin ich a) kein Freund von und b) unerfahren. Es gibt aber auch in 'normalen' SQL-Datenbanken die Möglichkeit, solche 'unscharfen' Dinge zu speichern, z.B. mit Key-Value-Storage (Beispiel: hstore in PostgreSQL).
Da würde man dann vielleicht das so speichern, daß das Dach eine Spalte ist, welche das alles enthält:

test=*# create table haus (id int, dach hstore);
CREATE TABLE
Time: 34,391 ms
test=*# insert into haus values (1,'Dachform=>Steildach,Steildach=>Satteldach,Satteldach=>symmetrisch,Konstruktion=>Holz,Dachdeckung=>Ziegel'::hstore);
INSERT 0 1
Time: 0,315 ms
test=*# commit;
COMMIT
Time: 0,481 ms
test=# select * from haus ;
 id |                                                               dach
----+----------------------------------------------------------------------------------------------------------------------------------
  1 | "Dachform"=>"Steildach", "Steildach"=>"Satteldach", "Satteldach"=>"symmetrisch", "Dachdeckung"=>"Ziegel", "Konstruktion"=>"Holz"
(1 row)

Time: 0,249 ms
test=*# select id, akeys(dach)from haus ;
 id |                          akeys
----+----------------------------------------------------------
  1 | {Dachform,Steildach,Satteldach,Dachdeckung,Konstruktion}
(1 row)

Mit der akeys() - Funktion kann man alle Keys des HSTORE ermitteln, es gibt weitere Möglichkeiten: http://www.postgresql.org/docs/9.2/static/hstore.html
Letztendlich kann man da auch drin suchen, auch indexbasiert. Aber die Datenbank kann nicht verhindern, daß man statt 'Dachform' sich vertippt und 'Dachforn' eingibt.
Es sei denn, Du hast alle erlaubten Eingaben irgendwo gespeichert -> als normalisierte Tabellen.

Was definitiv nicht geht ist die 'Riesentabelle', deren Nachteile hast Du ja schon erkannt. Da wirst vermutlich nie fertig neue Spalten dranzuklatschen. Und mit 'Normalisierung' kommst dem Wahnsinn auch sehr nah ;-)


Vielleicht hab ich ja geholfen ...

 

[weissnix]

Danke für die schnelle Antwort.

Stell Dir vor, Du willst Dir ein Haus konfigurieren (oder ein Auto).
Das ist eine lange Abfolge bedingter Abfragen als Listboxes.
Damit scheiden Tippfehler aus, was wichtig ist.
Es ist klar, dass hier jedes Bauteil in irgendeiner Tabelle stehen muss.
Die Frage ist: In wie vielen Tabellen?

In einem Haus gibt es sehr viele Bauteile. Für ein Steildach gibt es andere Dachdeckungen als für ein Flachdach.
Ein Ölheizkessel braucht einen Schornstein (mit bestimmten Durchmesser), eine Wärmepumpe nicht.

Das Kernstück meiner Software sind diese Abfragen.

Mein Problem ist wie gesagt, dass sich hier sehr viele winzige Tabellen ergeben, weil diese vielen unterschiedlichen Baustoffe nicht in 1, auch noch in 100 Tabellen passen.
Aber irgendwie finde ich, dass diese Winzigtabellen nichts mehr mit dem Grundgedanken einer DB zu tun haben.

Sicher gibt es dann einige große DB-Tabellen als Ausschreibungstexte und Preislisten.
Aber all das "Zeug" dazwischen, das sperrt sich irgendwie gegen das starre SQL-Schema, finde ich.

Natürlich programmiere ich das nicht selbst, bin ja Laie.
Aber ich muss trotzdem die Tabellen anlegen, weil das sehr baufachspezifisch ist.
Da bin also ich, von DB kaum Ahnung.
Und da ist ein Programmierer, der von Bauen keine Ahnung hat.

Da man erst dann was delegieren soll, wenn man es selbst (zumindest prinzipiell) verstanden hat, frag ich mich eben so durch.