Datenbankdesign

[dos]

Hallo,

ich habe hier folgenden gerichteten Multigraphen:

http://jsbin.com/aqupun/6/edit

wäre ein Tabellendesign wie folgendes hier sinnvoll?

Tabelle Edges
id|source_id|target_id
1 |1        |2
2 |1        |3
3 |1        |4

Tabelle nodes
id|name
1 |Jerry
2 |Elaine
3 |George
4 |Kramer

Wäre das dann eine one_to_many-Relation (one edge, many nodes)?

[dos]

Quatsch

Wäre das dann eine one_to_many-Relation (one edge, many nodes)?

one node, many edges meinte ich..

[Encoder]

one node, many edges meinte ich..

Du hast mehrere Kanten pro Knoten, also in der Tat eine 1:n Relation.
Dazu könnte mans auf deutsch aber auch sagen :-) Soll das noch was besonderes bedeuten? Ich kenne das nicht als geprägten Begriff.

[dos]

one node, many edges meinte ich..
Du hast mehrere Kanten pro Knoten, also in der Tat eine 1:n Relation.
Dazu könnte mans auf deutsch aber auch sagen :-) Soll das noch was besonderes bedeuten? Ich kenne das nicht als geprägten Begriff.

Hätte man auch auf deutsch sagen können, stimmt.

Aber mal ne andere Frage: Ich habe mehrere Kanten pro Knoten. Also 1 Knoten, mehrere Kanten. Aber eine Kante hat ja auch mehrere Knoten, nämlich normalerweise 2. (Es gibt in der Graphentheorie auch durchaus Kanten, die durch mehr als 2 Knoten gehen, aber das berücksichtige ich hier jetzt nicht). Das hat mich etwas verwirrt.

Ich habe das gestern nochmal durchdacht, das sollte passen. Eine andere Lösung ist mir zumindest nicht eingefallen.

[Encoder]

Aber eine Kante hat ja auch mehrere Knoten, nämlich normalerweise 2.

Deswegen speicherst du ja auch beide zu einer Kante. Anfang und Ende.

Aber mal ne andere Frage

Hab keine gefunden :-)

Das hat mich etwas verwirrt.

Was? Die Knoten zu einer Kante brauchen nicht in einer weiteren Verknüpfungstabelle (VerknüpfungsID, KnotenA, KnotenB) stehen, denn zwischen dieser Tabelle und den Kanten wäre wieder eine 1:1 Beziehung.
War das die Frage?

[Bobby]

Moin

Tabelle Edges
id|source_id|target_id
1 |1        |2
2 |1        |3
3 |1        |4

Tabelle nodes
id|name
1 |Jerry
2 |Elaine
3 |George
4 |Kramer

wozu benötigst du die id in der Tabelle Edges?? Die ist m.E. nicht notwendig da die Kombination aus source_id und target_id bereits als Primary Key fungieren können und somit einen eineindeutigen Schlüssel erzeugen.

Doppelte Einträge ware m.E. nach redundant und können so auch ausgeschlossen werden!

Gruß Bobby

[dos]

Hallo,

Tabelle Edges
id|source_id|target_id
1 |1        |2
2 |1        |3
3 |1        |4

wozu benötigst du die id in der Tabelle Edges?? Die ist m.E. nicht notwendig da die Kombination aus source_id und target_id bereits als Primary Key fungieren können und somit einen eineindeutigen Schlüssel erzeugen.

gut, akzeptiert. Allerdings gibt es noch weitere Tabellen, zum Beispiel

Tabelle edgeinformations
id|edge_id|value|description

dazu brauche ich eine eindeutige ID.

[Bobby]

Moin

Tabelle edgeinformations
id|edge_id|value|description

wenn du mehrere Einträge machen willst zu einer edge_id wird dies sicher sinnvoll sein. Wobei auch hier die Kombination edge_id und value die Schlüsselkandidaten für den PRIMARY-KEY sind. Wenn du nur einen Eintrag je Edge-ID haben möchtest ist sogar diese Edge-ID der Primary... Es kommt immer auf die Kardinalitäten an.

Gruß Bobby

[dos]

Halo

Tabelle edgeinformations
id|edge_id|value|description

wenn du mehrere Einträge machen willst zu einer edge_id wird dies sicher sinnvoll sein. Wobei auch hier die Kombination edge_id und value die Schlüsselkandidaten für den PRIMARY-KEY sind. Wenn du nur einen Eintrag je Edge-ID haben möchtest ist sogar diese Edge-ID der Primary... Es kommt immer auf die Kardinalitäten an.

du hast recht, die Tabelle muss natürlich so aussehen

Tabelle edgeinformations
id|value|description
wobei id die Id der Edge ist, da das eine 1:1-Relation ist (jede Edge hat eine Info und jede Info eine Edge).

Grundsätzlich zur ID:
ich dachte, gehört zu haben, dass man grundsätzlich eine tabelleninterne ai-ID vergeben soll. Was hälst du von dieser Aussage? Ich habe das bisher immer so gemacht, ist die Frage, ob das grundsätzlich sinnvoll ist. Denn dann wäre das ursprügnliche Design meiner "edgeinformations" eigentlich richtig im Sinne dieses Dogmas.

[Bobby]

Moin

Grundsätzlich zur ID:
ich dachte, gehört zu haben, dass man grundsätzlich eine tabelleninterne ai-ID vergeben soll. Was hälst du von dieser Aussage? Ich habe das bisher immer so gemacht, ist die Frage, ob das grundsätzlich sinnvoll ist. Denn dann wäre das ursprügnliche Design meiner "edgeinformations" eigentlich richtig im Sinne dieses Dogmas.

Da gibt es unterschiedliche Ansichten. Pro: nur eine Id und die noch autoincrement ist hilfreich um einen eineindeutigen key zu erzeugen. Man muss sich nicht drum kümmern. Außerdem sind kurze PK einfacher für das DBMS zu handlen

Contra: bei der verwendung einer id müssen auch alle felder als unique gekennzeichnet werden um die referentielle Integrität zu wahren und in der 3.NF zu bleiben. Und ob das weniger leistung benötigt als schlüsselkandidaten direkt als PK zu definieren, kann ich nicht beantworten.

Ich persönlich definiere das meiste ohne ID. Es sei denn es gibt keinen eineindeutigen schlüsselkandidaten.

Wenn jemand eine sinnvolle Erklärung zu definitiven Verwendung einer ID, so lasse ich mich gern vom Gegenteil überzeugen.

Gruß Bobby

[Bobby]

Moin

ich hab da noch was speziell für InnoDB gefunden: http://dev.mysql.com/doc/refman/5.1-olh/de/innodb-tuning.html

Gruß Bobby

[hotti]

hi,

Grundsätzlich zur ID:
ich dachte, gehört zu haben, dass man grundsätzlich eine tabelleninterne ai-ID vergeben soll.

Wenn Tabellen, die zusammengehören, jeweils alle ein auto-ID-Feld haben, kann die Abfrage LAST_INSERT_ID() mächtig in die Hose gehen ;)

Horst