n:m Relationen

Hallo,

Anfänger-Frage: ist es tatsächlich so vorgesehen, dass man bei einer
(n:m)-Relation zwischen zwei Entitäten 3 Tabellen hat und somit 3
Inserts ausführen muss/soll?

Die Frage klingt vielleicht etwas dumm, aber nehmen wir an, man hat eine
solche Relation in einer relationalen DB umgesetzt und hat zusätzlich
noch in jeder der Entitäten eine Auto_increment-ID als Primary Key, dann
muss man nach jedem Insert wieder die ID des zuletzt eingefügten
Datensatzes abfragen und dann in die Verbindungstabelle eintragen.

Also 2x Insert für die Entitäten + 2x Abfrage nach dem
Auto_intrement-Wert + 1x Insert in die Verbindungstabelle.

Das klingt nach nem gewaltigen Overhead! Je mehr man die Tabellen
normalisiert, desto schlimmer wird der ganze Kram. Da kommen dann bei
den Abfragennoch die ganzen JOINS dazu etc.

Irgendwann kann dadurch ein gewaltiger Engpass entstehen!

Re: n:m Relationen

Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de

Re: n:m Relationen

Mike Wesling schrieb:
> Hallo,
>
> Anfänger-Frage: ist es tatsächlich so vorgesehen, dass man bei einer
> (n:m)-Relation zwischen zwei Entitäten 3 Tabellen hat und somit 3
> Inserts ausführen muss/soll?

Ja.

> Die Frage klingt vielleicht etwas dumm,

ja.

> aber nehmen wir an, man hat eine solche Relation in einer
> relationalen DB umgesetzt und hat zusätzlich noch in jeder der
> Entitäten eine Auto_increment-ID als Primary Key, dann muss man nach
> jedem Insert wieder die ID des zuletzt eingefügten Datensatzes
> abfragen und dann in die Verbindungstabelle eintragen.

Ja, bei einer M:N sogar mehrfach. Du musst evtl sogar noch in einer
Tabelle suchen ob der Eintrag xxx schon vorhanden ist...

> Also 2x Insert für die Entitäten + 2x Abfrage nach dem
> Auto_intrement-Wert + 1x Insert in die Verbindungstabelle.

Ja, mindestens.

> Das klingt nach nem gewaltigen Overhead!

Nur auf den ersten Blick.

> Je mehr man die Tabellen normalisiert, desto schlimmer wird der ganze
> Kram. Da kommen dann bei den Abfragennoch die ganzen JOINS dazu etc.

Man kann sich auch /tot/ Normalisieren. Vor- und Nachnamen normalisiere
ich z.B. nicht.

Berechne mal das Kreuzprodukt einer umfangreichen M:N und denormalisiere
dann die Tabelle. Schreib ein Programm das solche Denormlaisierungen
verwaltet. Du wirst sehen das du noch VIEL mehr Aufwand machen musst und
mehr Speicher verbrätst.

> Irgendwann kann dadurch ein gewaltiger Engpass entstehen!

Nein. Ein Join ist nicht so teuer wie viele vielleicht denken! Zumindest
bei passenden Indizes.

Re: n:m Relationen

Mike Wesling schrieb:

> Anfänger-Frage: ist es tatsächlich so vorgesehen, dass man bei einer
> (n:m)-Relation zwischen zwei Entitäten 3 Tabellen hat und somit 3
> Inserts ausführen muss/soll?

Ja.

> [...]
> Also 2x Insert für die Entitäten + 2x Abfrage nach dem
> Auto_intrement-Wert + 1x Insert in die Verbindungstabelle.
>
> Das klingt nach nem gewaltigen Overhead! Je mehr man die Tabellen
> normalisiert, desto schlimmer wird der ganze Kram. Da kommen dann bei
> den Abfragennoch die ganzen JOINS dazu etc.

Ja, das kam mir Damals[tm] bei meinem Einstieg in Datenbanken
auch gnadenlos umständlich vor. Seit ich mir mit einem
nichtnormalisierten Datenbankdesign sauber ins Knie geschossen
habe, sehe ich das fundamental anders.
Glaub mir: Wenn Du irgendwann mal vorhast, aus Deiner Datenbank
Informationen 'rauszukitzeln, die ein wenig komplexer als "gib
mir einfach alles" sind, wirst Du um ein normalisiertes
Datenbankdesign dankbar sein.
Zumal man ja in geschätzt >99% aller Fälle die JOIN-Konstrukte
zur Abfrage irgendwo in die Applikationsebene einbaut, wo man sie
nur einmal programmiert und fürderhin einfach nur auf ein paar
bunte Buttons klickt.

> Irgendwann kann dadurch ein gewaltiger Engpass entstehen!

Engpaß? Wovon sprichst Du?


Tschüs,

Sebastian

Re: n:m Relationen

Mike Wesling schrieb:

> Anfänger-Frage: ist es tatsächlich so vorgesehen, dass man bei einer
> (n:m)-Relation zwischen zwei Entitäten 3 Tabellen hat und somit 3
> Inserts ausführen muss/soll?

3 INSERTs sind nur dann nötig, wenn Du in die beiden Stammtabellen je
einen neuen Eintrag vornehmen und diese gleich miteinander verlinken
möchtest. Das ist jedoch eher selten der Fall.

Wesentlich häufiger hast Du den Fall, bereits vorhandene Einträge
miteinander verlinken zu wollen (Kunde X kauft Artikel Y). In diesen
Fällen hast Du nur noch _einen_ INSERT.

> Die Frage klingt vielleicht etwas dumm, aber nehmen wir an, man hat eine
> solche Relation in einer relationalen DB umgesetzt und hat zusätzlich
> noch in jeder der Entitäten eine Auto_increment-ID als Primary Key, dann
> muss man nach jedem Insert wieder die ID des zuletzt eingefügten
> Datensatzes abfragen und dann in die Verbindungstabelle eintragen.

Deine Schilderung klingt irgendwie nicht nach n:m, sondern eher nach
1:1. Dafür benutzt man normalerweise _eine_ Tabelle.

> Also 2x Insert für die Entitäten + 2x Abfrage nach dem
> Auto_intrement-Wert + 1x Insert in die Verbindungstabelle.

In diesem speziellen Fall: Ja.

> Das klingt nach nem gewaltigen Overhead!

Im Gegenteil: Ohne eine dritte Tabelle bekommst Du einen noch viel
gewaltigeren Overhead.

Stell Dir mal vor, Du hast einen Versandhandel. Hierzu benötigst Du
einen Artikelstamm für Deine Artikel, einen Kundenstamm für Deine Kunden
und eine Auftragsliste für die Aufträge.

Zwischen Auftrag und Artikel hast Du die klassische n:m-Beziehung (ein
Auftrag kann mehrere Artikel enthalten, ein Artikel kann in mehreren
Aufträgen vorkommen). Wie möchtest Du das, ohne eine dritte Tabelle
bemühen zu müssen, realisieren? Wie müssen Deine Abfragen dann aussehen,
wenn Du wissen möchtest, welche Artikel in einem bestimmten Auftrag
auftauchen und welche Aufträge einen bestimmten Artikel enthalten?

> Irgendwann kann dadurch ein gewaltiger Engpass entstehen!

Engpässe entstehen durch so etwas nicht. Engpässe entstehen eher durch
fehlerhafte Indizierung der beteiligten Tabellen oder durch ein kaputtes
Datenbankdesign.

Gruß. Claus

Re: n:m Relationen

Mike Wesling meinte:
> Hallo,
>
> Anfänger-Frage: ist es tatsächlich so vorgesehen, dass man bei einer
> (n:m)-Relation zwischen zwei Entitäten 3 Tabellen hat und somit 3
> Inserts ausführen muss/soll?

Ja.

> Die Frage klingt vielleicht etwas dumm, aber nehmen wir an, man hat eine
> solche Relation in einer relationalen DB umgesetzt und hat zusätzlich
> noch in jeder der Entitäten eine Auto_increment-ID als Primary Key, dann
> muss man nach jedem Insert wieder die ID des zuletzt eingefügten
> Datensatzes abfragen und dann in die Verbindungstabelle eintragen.

Nur wenn eine Zuordnung des neuen Datensatzes zur anderen Tabelle erfolgt.

> Also 2x Insert für die Entitäten + 2x Abfrage nach dem
> Auto_intrement-Wert + 1x Insert in die Verbindungstabelle.

Eher selten. Die Anlage eines Datensatzes in einer Tabelle bedingt ja
keine zwingenden Anlagen in den anderen.

> Das klingt nach nem gewaltigen Overhead! Je mehr man die Tabellen
> normalisiert, desto schlimmer wird der ganze Kram. Da kommen dann bei
> den Abfragennoch die ganzen JOINS dazu etc.

Ja. Furchtbar. Grauenhaft.

> Irgendwann kann dadurch ein gewaltiger Engpass entstehen!

Wie meinen? RDBMS sind darauf *spezialisiert*. Oder meinst du einen
"Engpass" beim Programmierer.

Gruß, Gregor


--
http://www.gregorkofler.at ::: Landschafts- und Reisefotografie
http://www.licht-blick.at ::: Forum für Multivisionsvorträge
http://www.image2d.com ::: Bildagentur für den alpinen Raum

Re: n:m Relationen

Mike Wesling schrieb:
> Hallo,
>
> Anfänger-Frage: ist es tatsächlich so vorgesehen, dass man bei einer
> (n:m)-Relation zwischen zwei Entitäten 3 Tabellen hat und somit 3
> Inserts ausführen muss/soll?

Ja.
Deswegen wird ja seit zig Jahren am Thema "objektorientierte
Datenbanken" geforscht, weil da weniger Verrenkungen für mehr Ergebnis
möglich sein sollten - allerdings dominieren (momentan noch?) die
relationalen Datenbanken, in denen man eben so wie von Dir beschrieben
vorgeht. Na ja, vielleicht könnte man sich die mittlere Tabelle in
Einzelfällen sparen, wenn man die Referenzen in Array-Spalten ablegt.
Habe ich aber noch nie gesehen, vermutlich, weil die Handhabung davon
noch schrecklicher ist als die der zusätzlichen Tabelle für die
Abbildung der Relation.

Ciao

Tobi

Re: n:m Relationen

Andreas
--
q: why do so many people take an instant dislike to mysql?
a: it saves time (oicu in #postgresql)
Explaining the concept of referential integrity to a mysql user is like
explaining condoms to a catholic (Shadda in #postgresql)

Re: n:m Relationen

> Die Frage klingt vielleicht etwas dumm, aber nehmen wir an, man hat eine
> solche Relation in einer relationalen DB umgesetzt und hat zusätzlich
> noch in jeder der Entitäten eine Auto_increment-ID als Primary Key, dann
> muss man nach jedem Insert wieder die ID des zuletzt eingefügten
> Datensatzes abfragen und dann in die Verbindungstabelle eintragen.

Für die Verknüpfungstabelle brauchst Du mittlerweile selbst bei MySQL
keinen separaten Primärschlüssel mehr, Du kannst einfach den linken und
den rechten Schlüssel gemeinsam als Primärschlüssel definieren.

Bei einer Schreiboperation hast Du ja meistens schon eine ID, da Du ja
z. B. einem Neueintrag Filmstar Filme zuordnest oder einem Neueintrag
Filme die Darsteller (klassische n:m-Beziehung).

> Also 2x Insert für die Entitäten + 2x Abfrage nach dem
> Auto_intrement-Wert + 1x Insert in die Verbindungstabelle.
>
> Das klingt nach nem gewaltigen Overhead! Je mehr man die Tabellen
> normalisiert, desto schlimmer wird der ganze Kram. Da kommen dann bei
> den Abfragennoch die ganzen JOINS dazu etc.
>
> Irgendwann kann dadurch ein gewaltiger Engpass entstehen!

Was ist die Alternative? Ich habe schon Zeugs gesehen wie bei "n" die
Werte von M als CSV in einen Blob zu schreiben (Wer möchte, tue sich das
Datenbankdesign von Typo3 an).
Nur: dort musst Du bei jeder Lösch- und Schreiboperation das ganze Ding
auslesen, abändern, neu schreiben. Beim Abfragen kannst Du ne
Volltextsuche machen. Oder Du fragst es nie wieder ab. DAS ist ein Engpass.
--
Mein Zeugs:
http://www.hadanite-marasek.de/classes.php
http://www.objektivsuche.de/

Re: n:m Relationen

> Man kann sich auch /tot/ Normalisieren. Vor- und Nachnamen normalisiere
> ich z.B. nicht.

Was ist dazu normalisieren? Das sind doch bestenfalls die gleichen, nicht
dieselben Namen.
Nagut, bei Ehepartnern, aber sonst... ;)