Beziehungen

[marega]

Hallo zusammen,

bei vielen Übungsdatenbanken oder Tutorials gibt es viele verschiedene Tabellen mit den einzelnen Beziehungen.
Nach der einen oder anderen Join Abfrage, bei der ich mehrere Tabellen zusammenführen musste um an die Info aus einer bestimmten Tabelle zu kommen.

Wäre es denn nicht praktischer eine Art Navigationstabelle zu erstellen, in der alle primary keys enthalten sind? Anstelle immer nur jeweils eine Tabelle mit einer nachfolgenden zu verknüpfen?

Um so immer nur max. 3 Tabellen mit einander verknüpfen zu müssene? Sprich: table1 <-> nav-table <-> table 5

Wieso ist das nicht Standard? Was spricht dagegen?

 

[akretschmer]

Wäre es denn nicht praktischer eine Art Navigationstabelle zu erstellen, in der alle primary keys enthalten sind? Anstelle immer nur jeweils eine Tabelle mit einer nachfolgenden zu verknüpfen?

Um so immer nur max. 3 Tabellen mit einander verknüpfen zu müssene? Sprich: table1 <-> nav-table <-> table 5

Wieso ist das nicht Standard? Was spricht dagegen?

So ganz kann ich Dir nicht folgen, aber vermutlich spricht das relationale Datenbankdesign dagegen. Kannst Du ein Beispiel, welche Übungsaufgabe bzw. dessen Lösung Du wie grandios verbessern willst?

 

[marega]

in vielen Aufgaben sehe ich folgenden Aufbau:

table1 table2 table3 table4 table5
--------- ------- ---------------- ------------- --------------
table1ID (PK) | table2ID (PK) | table3ID (PK) | table4ID (PK) | table5ID (PK)
name | table1ID (FK) | table2ID (FK) | table3ID (FK) | table4ID (FK)
xyz | abc | etc . | | usw | usf

Möchte ich Informationen abfragen, die table1 und table5 betrifft, muss ich table1 mit table 2, und table 2 mit table3 usw. joinen. Bis alle miteinander ge-join-t wurden, obwohl table2 z.b. mit der Ausgabe nichts zu tun hat.
Hätte ich anstelle dessen eine Navigationstabelle mit table1ID, table2ID, table3ID, table4ID mit den richtigen FKs, müsste ich doch nur noch table1 <-> navi_table <-> table5 verknüpfen, um informationen aus table1 und table5 abzufragen, ohne table- 2|3|4 zu involvieren

 

[akretschmer]

in vielen Aufgaben sehe ich folgenden Aufbau:

table1 table2 table3 table4 table5
--------- ------- ---------------- ------------- --------------
table1ID (PK) | table2ID (PK) | table3ID (PK) | table4ID (PK) | table5ID (PK)
name | table1ID (FK) | table2ID (FK) | table3ID (FK) | table4ID (FK)
xyz | abc | etc . | | usw | usf

Möchte ich Informationen abfragen, die table1 und table5 betrifft, muss ich table1 mit table 2, und table 2 mit table3 usw. joinen. Bis alle miteinander ge-join-t wurden, obwohl table2 z.b. mit der Ausgabe nichts zu tun hat.
Hätte ich anstelle dessen eine Navigationstabelle mit table1ID, table2ID, table3ID, table4ID mit den richtigen FKs, müsste ich doch nur noch table1 <-> navi_table <-> table5 verknüpfen, um informationen aus table1 und table5 abzufragen, ohne table- 2|3|4 zu involvieren

Nun ja, für Datenbanken ist aber exakt das, was sie gut können. Zumindest so lange die Anzahl der Joins in einem überschaubaren Rahmen bleiben.

Ein Freund von mir, Hans-Jürgen Schönig, wird in wenigen Wochen zur PGCONF.EU zeigen, welche Probleme man bekommt, wenn das etwas mehr Tabellen werden - konkret 1 Million JOINs. Es gibt schon einen Vorbericht dazu, hier: http://www.cybertec.at/next-stop-joining-1-million-tables/ , ich weiß, daß er für die da genannten Probleme auch eine Lösung hat.
Die zeigt er jetzt natürlich noch nicht, soll ja spannend bleiben ;-)

Das, was Du ansprichts, geht auch so einfach nicht. Zum einen hat man nicht immer einen 1:1 - Join, zum anderen müßte diese Tabelle auch immer aktuell gehalten werden.

Beispiel:

Du hast Schulen, Klassen, Schüler.

test=# create table schule(id int primary key, name text);
CREATE TABLE
Time: 281,416 ms
test=*# create table klasse(id int primary key, schule_id int references schule, name text);
CREATE TABLE
Time: 75,170 ms
test=*# create table schueler(id int primary key, klasse_id int references klasse, name text);
CREATE TABLE
Time: 23,980 ms

Wie sollte nun Deine Navigantionstabelle aussehen, undwelche Vorteile erwartest Du?

 

[Hony%]

Möchte ich Informationen abfragen, die table1 und table5 betrifft, muss ich table1 mit table 2, und table 2 mit table3 usw. joinen. Bis alle miteinander ge-join-t wurden, obwohl table2 z.b. mit der Ausgabe nichts zu tun hat.

Das relationale Datenbankmodel basiert nun mal auf Relationen. In Andreas Beispiel kann es auch eine Tabelle mit den geleisteten Arbeitsstunden der Lehrer geben. Diese hängen natürlich indirekt über n Ecken mit jedem einzelnen Schüler zusammen.

Hätte ich anstelle dessen eine Navigationstabelle mit table1ID, table2ID, table3ID, table4ID mit den richtigen FKs, müsste ich doch nur noch table1 <-> navi_table <-> table5 verknüpfen, um informationen aus table1 und table5 abzufragen, ohne table- 2|3|4 zu involvieren

Ich bin mir ziemlich sicher, dass eine solche Navigationstabelle gegen die 3. Normalform verstoßen würde. Stichwort: Transitive Funktionale Abhängigkeiten

Welche Probleme du dir damit einhandelst findest du unter dem Stichwort: Datenbank Anomalien

Gruß
Hony

 

[ukulele]

Im Prinzip wäre es möglich eine Art Code-Verkürzer per dynamischem SQL zu basteln. Der würde dann aus deinen Angaben Tabelle 1 und Tabelle 5 über eine Navitabelle den Join zusammenkleben. Das wäre aber nach meiner Einschätzung mächtig kompliziert und nur selten wirklich nützlich. Vor allem würde es nur die Arbeit, den Join aufzuschreiben ersparen, was ja jetzt nur mäßig aufwendig ist.

Probleme gäb es aber viele. Was wenn deine Tabellen mehr als eine Relation miteinander haben? Wie findest du den Pfad über Tabelle 2 3 und 4, per Routenplanung?