Frage zu mysql

Question

Hallo zusammen,

ich habe ein Verständnisproblem ;-):

Nehmen wir an, ich habe verschiedene Tabellen, z.B.: tabelle_kunde_stammdaten (name, straße, id, plz_id)
tabelle_plz (plz_id, plz, ort)

Wenn ich nun alle Daten zusammen ausgeben möchte, mache ich, wenn ich es richtig verstanden habe, einen leftjoin.

soweit, sogut.
aber wozu setze ich eine Referenz zwischen den beiden Tabellen?
Die Verknüpfung entsteht doch durch den join, oder?

Oder ist die Referenz nur dazu da, verwaiste Datensätze zu vermeiden bzw. festzulegen, wie mit dem referenzierten Datensatz vorgegangen werden soll (z.B. on delete -> cascade)?

Wäre super nett, wenn ihr mir auf die Sprünge helft.

Vielen Dank im Voraus.
lg

Answer 1

Hallo

erstmal wenn du alle daten einer Tabelle haben möchtest auch wenn in der anderen kein passender datensatz ist dann left join. Sonst inner Join

SELECT * FROM
Tabelle_kunde_stammdaten
LEFT JOIN
tabelle_plz
ON
Tabelle_kunde_stammdaten.plz_id=tabelle_plz.plz_id

Wenn du nun eine Postleitzahl löscht wird natürlich nicht automatisch auch alle kunden gelöscht oder umgekehrt, das wäre auch meistens ziemlich unsinnig.

Wenn es eine 1:1 beziehung ist dann brauchst du nämlich keine 2 Tabellen zu machen sondern kannst die Daten alle in eine Tabelle packen.

eine aufteilung in 2 Tabellen macht nur sinn wenn du eine 1:n oder n:n verbindung von Daten hast, also die daten einer Tabelle mehrmals in der anderen vorkommen können.

du löscht ja nicht die Postleitzahl und den Ort nur weil du keinen Kunden hast der da wohnt.


du kannst aber (was im gegeben beispiel vielleicht interessant ist) nach Kunden suchen, die eine Postleitzahlid haben, die in der anderen Tabelle nicht vorkommt und wo dann der rechte teil eines Left joins nur null-werte ausgibt z.B.

SELECT * FROM
Tabelle_kunde_stammdaten
LEFT JOIN
tabelle_plz
ON
Tabelle_kunde_stammdaten.plz_id=tabelle_plz.plz_id
WHERE tabelle_plz.plz IS NULL

würde dir durchaus empfehlen die Postleitzahl als primary key zu benutzen und nicht noch eine id-spalte, ob du nun ein 32Byte Integer wert einer ID vergleichst oder ein 5 Byte NVARCHAR-feld kommt für SQL ziemlich aufs gleiche raus und du hast jede Postleitzahl garantiert nur einmal drin.


Wenn du häufig bestimmte verknüpfungen verwendest, erstellst du (oder hast du vielleicht schon) eine View.

mit ONDELETE oder ONUPDATE wäre ich vorsichtig, das wird selten wirklich gebraucht


Mfg
MixMax

Answer 2

Hallo MixMax,

vorweg Mal vielen Dank für deine Antwort.

Die Sache mit den plz ist doch eine 1:n-Beziehung, oder?
Eine plz kann bei mehreren Kunden vorkommen.

Betreffend on delete etc. hast du sicher recht. Da bin ich schon eher skeptisch, würde ich lieber keine Aktion angeben :-)

Aber noch zu meiner eigentlichen Frage: Wenn ich die Beziehungen doch über joins herstelle, wozu brauche die Referenzierung?
Also das mit den Krähenfüßen, Kardinalitäten etc.?
Oder brauche ich das nicht, wenn ich keine on delete etc. machen möchte?

lg

Answer 3

Was bezeichnest du als "Referenz", was du in MySQL erstellen kannst sind VIEWS.

Also wenn du ohne ondelete/onupdate auskommst, ist es eigentlich egal ob du dem Server sagst das 2 Tabellen miteinander verbunden sind oder nicht.

Eine View spart dir die arbeit, bei jeder Abfrage den kompletten join neu schreiben zu müssen und einfach deinen Select auf die View machst.
Außerdem kannst du mit einer View die Ausgabe von normalerweise nicht benötigten Spalten steuern oder Zeilen grundsätzlich rausfiltern.
(habe ich neulich mal gemacht weil ich z.B. von einer View immer nur aktive Mitglieder ausgegeben bekomme)

Answer 4

Hallo,

das klingt interressant mit den views, werde ich mir auch mal anschauen. Das habe ich bisher überblättert. Danke auch für den Tip mit Primärschlüssel auf plz, habe ich schon geändert.

Ich meine mit Referenz die Relationen.
Primärschlüssel und Fremdschlüssel referenzieren einander.
Dann hat man diese winkeligen Verbindungsstriche, die man überall bei der Abbildung eines ER-Diagramms sieht.

z.B. hier: www.karlhaak.de/seiten/datenbanken/erdiagramme.asp

Aber wenn ich da zu theoretisch unterwegs bin und das gar nicht brauche, soll es mir recht sein. Ich habe mich glaube ich ohnehin schon zu viel mit Theorie beschäftigt ohne mich richtig in die Praxis zu stürzen... verdammter Perfektionismus :-)

lg

Answer 5

das ist nicht falsch mit der Theorie, es ist superwichtig sich gedanken über die Relationen zu machen und zu überlegen welche daten man in einer Tabelle direkt speichert und welche man mit einer anderen verknüpft... zum Beispiel um den Zustand von Daten zu einem alten Zeitpunkt nicht zu verlieren.

Aber für MySQL sind es einfach 2 Tabellen, der Server macht nichts von selber automatisch nur weil du die Daten verknüpft hast.

Daten solltest du z.B. nicht indirekt verknüpfen wenn du etwas zu einem Datum speicherst was an einem Datum passiert ist.

z.B.

3 Tabellen:
Event (id, datum, mitarbeiterid)
Mitarbeiter (id, name, vorgesetzterid)
Vorgesetzte (id, name)

Würde man den Vorgesetzten NUR über den Mitarbeiter verknüpfen, ändert sich die Ausgabe dahingehend das obwohl zum Event der Mitarbeiter einen anderen Vorgesetzten hatte, immer der aktuelle Vorgesetzte angezeigt wird.

Vorgesetzte können wechseln also kann es sinnvollsein die Tabelle Event so zu gestallten:
Event (id, datum, mitarbeiterid, vorgesetzterid)

Wird es an beiden Stellen verknüpft, läßt sich beides feststellen - wer jetzt Vorgesetzter ist und wer zum Zeitpunkt des Events der Vorgesetzte war.