nicht angemeldet
Verknüpfungen
Hallo!
Ich hätte da eine Frage bezüglich der Struktur einer Datenbank. Wie soll ich eine Datenbank planen bei der verschiedene Tabellen miteinander verknüpft sind?
Dies ist der grobe Aufbau der Datenbank:
id -> Tabelle1
|
|-- pid id -> Tabelle2
|
|-- pid id -> Tabelle3
|
|-- pid id -> Tabelle4
Jetzt folgendes: Wenn ich nun in der Tabell4 einen Datensatz suche, der mit Tabelle1 verknüpft ist, dann löse ich das mit einem JOIN über Tabelle2.
Meine Frage ist nun, ist es nicht sinnvoller gleich bei Dateneingabe die id der Tabelle1 in der Tabelle4 abzuspeichern? Somit könnte man sich doch den JOIN sparen?
id -> Tabelle1
|
|-- pid1 id -> Tabelle2
| |
| |-- pid2 id -> Tabelle3
| |
|-- pid4 |-- pid2 id -> Tabelle4
Was spricht dagegen?
bitte um tipps
& lg lixx
-
Hallo lixx,
um die Tabellen zu Verknüpfen sollte man im Normalfall, falls möglich mit Fremdschlüsseln arbeiten. Ein Fremdschlüssel in einer Kindertabelle kann nur auf eine anderen Tabelle als Vatertabelle verweisen. Somit könntest du keine Fremdschlüssel setzen, wenn du nach deinem 2. Ansatz arbeitest.
Was ich mich allerdings frage: Müssen es 4 Tabellen sein? Wenn die Struktur der Daten in allen diesen Tabellen annähernd identisch ist, dann würde sich das Arbeiten mit nur einer Tabelle empfehlen!
MFG
ProXy-
Danke für die Antwort.
um die Tabellen zu Verknüpfen sollte man im Normalfall, falls möglich mit Fremdschlüsseln arbeiten.
Ich habe davon bereits im Handbuch gelesen - Verwendet wird MySQL 4.1.2 - aber ich bin daraus nicht schlau geworden wie das funktioniert.
Was ich mich allerdings frage: Müssen es 4 Tabellen sein? Wenn die Struktur der Daten in allen diesen Tabellen annähernd identisch ist, dann würde sich das Arbeiten mit nur einer Tabelle empfehlen!
Die gesamte db ist weitaus komplexer als dieses Beispiel. die verschiedenen Tabellen dienen unterschiedlichen Themen - oder Module, wenn man so will. Die Darstellung dient nur der Veranschaulichung.
-
Ich habe davon bereits im Handbuch gelesen - Verwendet wird MySQL 4.1.2 - aber ich bin daraus nicht schlau geworden wie das funktioniert.
Beim Setzen von sog. Fremdschlüsseln können in die Spalten einer "Kind"-Tabelle nur Werte eingegeben können, die auch der Vater besitzt. Während dies bei nahezu allen DBMS der Fall ist, hinkt mySQL da wieder hinterher. mySQL bietet mehrere Storage Engines, die sich in Geschwindigkeit und Umfang unterscheiden. Die Engine innoDB - welche leider nicht Standard ist - bietet dir die Möglichkeit mit Fremdschlüsseln zu arbeiten.
Vor allem bei grösseren Projekten solltest du auf alle Fälle sicherstellen, dass alle Constraints richtig gesetzt sind - nur so kannst du Datenmüll verhindern.
MFG
ProXy-
Ilja
und je nach art der beziehungen (1:n oder n:m) der entitäten ... welche tabellen du brauchst, bzw. wieviele.Dabei handelt es sich um l:n-Beziehungen. Und die Tabellen werden alle benötigt. Es gibt dann auch noch weitere.
Die Frage ist ja nur, ob es besser ist (ohne Fremdschlüssel) die gesamte Baumhirarchie hinunter zu klettern (in dem Fall mit JOINs) oder ob man von vornherein eine Verknüpfung mit der Wurzel herstellt.
ProXy
Beim Setzen von sog. Fremdschlüsseln können in die Spalten einer "Kind"-Tabelle nur Werte eingegeben können, die auch der Vater besitzt. Während dies bei nahezu allen DBMS der Fall ist, hinkt mySQL da wieder hinterher. mySQL bietet mehrere Storage Engines, die sich in Geschwindigkeit und Umfang unterscheiden. Die Engine innoDB - welche leider nicht Standard ist - bietet dir die Möglichkeit mit Fremdschlüsseln zu arbeiten.Ach ja, jetzt kann ich mich wieder daran erinnern. Habe auch nochmals im Handbuch nachgesehen. Ich habe das schon einmal mit einer innoDB versucht. Bin dann aber wieder zu MyISAM gewechselt. Das mit den Fremdschlüsseln möchte ich vorerst einmal bleiben lassen.
-
yo,
Dabei handelt es sich um l:n-Beziehungen. Und die Tabellen werden alle benötigt. Es gibt dann auch noch weitere.
Die Frage ist ja nur, ob es besser ist (ohne Fremdschlüssel) die gesamte Baumhirarchie hinunter zu klettern (in dem Fall mit JOINs) oder ob man von vornherein eine Verknüpfung mit der Wurzel herstellt.
je nachdem, um welche art von 1:n beziehungen es sich handelt, kann es sein, dass du die tabelle2 überspringen kannst. wenn zum beispiel tabelle1 den fremdschlüssel von tabelle2 enthält und tabelle4 ebenfalls, dann kannst du die beiden fremdschlüssel miteinander verbinden, ohne über die tabelle2 und deren pk gehen zu müssen.
aber wie gessagt, das hängt alles davon ab, welche entitäten du hast und um welche beziehungen es sich genau handelt. solange du da nicht ein wenig mehr infos heraus gibst, ist es schwer zu beurteilen.
Ilja
-
je nachdem, um welche art von 1:n beziehungen es sich handelt, kann es sein, dass du die tabelle2 überspringen kannst. wenn zum beispiel tabelle1 den fremdschlüssel von tabelle2 enthält und tabelle4 ebenfalls, dann kannst du die beiden fremdschlüssel miteinander verbinden, ohne über die tabelle2 und deren pk gehen zu müssen.
Wie gesagt sind das dann nur "virtuelle" Fremdschlüsseln, da ich MyISAM verwende. Aber ich denke, dass das wohl die beste Lösung ist, obwohl sie etwas unübersichtlich mit der Zeit wird.
aber wie gessagt, das hängt alles davon ab, welche entitäten du hast und um welche beziehungen es sich genau handelt. solange du da nicht ein wenig mehr infos heraus gibst, ist es schwer zu beurteilen.
Die Beziehungen sind so wie dargestellt. Mehr fällt mir nicht ein dazu zu sagen. Ich wüsste auch nicht, wie anderst darstellen.
id -> Tabelle1
|
|-- pid id -> Tabelle2
|
|-- pid id -> Tabelle3
|
|-- pid id -> Tabelle4Die Inhalte der Tabellen ist in etwa so:
id -> Account
|
|-- pid1 id -> User
| |
| |-- pid2 id -> Autos
| |
|-- pid4 |-- pid2 id -> DVDslg lixx
-
yo,
Wie gesagt sind das dann nur "virtuelle" Fremdschlüsseln, da ich MyISAM verwende. Aber ich denke, dass das wohl die beste Lösung ist, obwohl sie etwas unübersichtlich mit der Zeit wird.
virtuelle fremdschlüssel gibt es nicht, bei MyISAM sind es genauso fremdschlüssel, wie bei allen anderen auch, nur das sich nicht die funktionalität der referentiellen integrität bieten. aber fremdschlüssel bleibt fremdschlüssel und bildet unter anderem die beziehungen bei rdbms ab.
Die Beziehungen sind so wie dargestellt. Mehr fällt mir nicht ein dazu zu sagen. Ich wüsste auch nicht, wie anderst darstellen.
mich interessiert weniger die umsetzung, sondern welche fachlichen entitäten dahinter stecken. aus dem digramm kann nicht erkennen, was die tabellen eigentlich aus der realen welt abbilden. dies ist aber entscheident, um aussagen über das gewählte design machen zu können. oder mit anderen worten, mich interessiert erst mal weniger das ergebnis, sondern wie sieht die umgebung aus, die du abbilden willst.
Ilja
-
-
-
-
-
-
-
yo,
Meine Frage ist nun, ist es nicht sinnvoller gleich bei Dateneingabe die id der Tabelle1 in der Tabelle4 abzuspeichern? Somit könnte man sich doch den JOIN sparen?
die planung hat erst einmal wenig mit joins und fremdschlüssel zu tun, sondern man versucht erst einmal die jeweilge umgebung in einem modell widerzugeben, welche entitäten benötige ich überhaupt, welche beziehungen gibt es zwischen diesen entitäten, etc.
und je nach art der beziehungen (1:n oder n:m) der entitäten und der technik (rdbms) entscheidet sich, welche tabellen du brauchst, bzw. wieviele. in deinem falle bedeutet das, welche beziehungen gibt es zwischen der entität aus tabelle1 und tabelle4.
deswegen ist deine frage nicht zu beantworten, solange wird nicht die entitäten kennen, die sich hinter deinen tabellen verstecken, bzw. die beziehungen deiner entitäten.
Ilja