SQL JOIN OHNE Fremdschlüssel?!

[chuya194]

Hi zusammen,

ich stehe gerade aufm Schlauch.
Ich spiele gerade bisschen mit SQL Abfragen rum...
Beim Punkt JOIN OHNE Fremdschlüssel einer Tabelle komme ich nicht weiter?!
Wie vergleiche ich auf 2 Werte, wenn in der zweiten Tabelle KEIN Fremdschlüssel ist?!

Danke

 

[Daaron]

Du brauchst keine FOREIGN KEYs in der 2. Tabelle... du kommst aber nicht um JOIN ... ON ... herum

 

[chuya194]

hmhmhm... okay.

Noch eine Frage:

Ich habe eine Tabelle in der ich eine Zeile per "sum funktion" summiere
In der zweiten Tabelle(Kein foreign key) summiere ich wieder eine Zeile
Summe Zeile 1 - Summe Zeile 2, auf was muss ich beim JOIN.. ON... achten damit das alles nicht multipliziert wird?!

 

[Daaron]

Was für eine eigenartige Tabellenstruktur hast du, dass du eine Summenfunktion auf eine Zeile anwenden kannst?

Denk immer daran:
The key, the whole key and nothing but the key, so help me Codd!

 

[Hancock]

Du meinst mit multiplizieren, dass die Summe nur über das Ergebnis des Joins geht?
Völlig egal! Du musst dir die sum-Funktion so vorstellen, dass zuerst die ganze Tabelle generiert wird wie als wär kein sum da, dann wird diese Tabelle aufgesummt und das ist das Ergebnis.

Lass sum weg und du siehst die "Quelldaten", die sum verwendet.

PS: "select from a join b on c=d" ist (fast) das gleiche wie "select from a,b where c=d"

 

[mambokurt]

hmhmhm... okay.

Noch eine Frage:

Ich habe eine Tabelle in der ich eine Zeile per "sum funktion" summiere
In der zweiten Tabelle(Kein foreign key) summiere ich wieder eine Zeile
Summe Zeile 1 - Summe Zeile 2, auf was muss ich beim JOIN.. ON... achten damit das alles nicht multipliziert wird?!

Ich denke mal eher du summierst Spalten, nicht Zeilen. Und multipliziert wird da gar nichts Ansonsten kann ich dir nur arg empfehlen solche Fragen mit einem kleinen Beispiel zu versehen, ansonsten erklären dir 10 verschiedene Leute 10 verschiedene Lösungen für das jeweils von ihnen verstandene Problem.

Vielleicht zum generellen Verständnis ein paar Sachen die mir nicht ganz eingängig waren, das wird dir sicherlich mehr helfen als spezifische Erklärungen:

*Du führst Abfragen immer auf Zeilen aus, Aggregatsfunktionen wie max, sum, etc werden aber immer auf Spalten ausgeführt.
*Du führst deine Abfrage immer auf eine Tabelle aus. Ein Join ist nichts weiter, als wenn du deine Ursprungstabelle um die gejointe Tabelle erweiterst. LEFT JOIN/ RIGHT JOIN /INNER / OUTER sagt dabei nur aus, welches deine Anfangstabelle ist und was passiert, wenn Joinbedingungen für mehr als eine Zeile zutreffen.
*Jede Unterabfrage liefert ihrerseits nur eine Tabelle zurück, das heißt du kannst auf Unterabfragen genauso joinen wie auf stinknormale Tabellen

Kurzer Denkanstoß:
SELECT * FROM (SELECT 'hui' AS A, 'bui' AS B) tbl LEFT JOIN tabelle tbl2 ON tbl.A = tabelle.Spaltenname

und nein: da fehlt kein Tabellenname im Subselect ;D

*Wenn du Aggregatsfunktionen verwendest und ein Group by benutzt, mußt du jedes Feld das du selektierst und was nicht in einer Aggregatsfunktion verwendet wird, in ein GROUP BY packen. Ansonsten würde die Datenbank 'raten' welche Sätze wegfallen. Schlomodatenbanken wie Mysql und SQLite erlauben das, aber gewöhn es dir bloß nicht an.
*Foreign Keys als Constraints sind nice to have, aber mehr auch nicht. Ich an deiner Stelle würde mir da gar keine Gedanken drum machen, maximal das Kapitel im Handbuch lesen und im Hinterkopf behalten, dass es soetwas gibt.

 

[Hancock]

Foreign Keys sind mehr als nice to have, sie schützen dich vor Dummheiten wie Datensätze, die die Integrität der DB verletzten würde, einzufügen oder welche, die du brauchst zu löschen. (ON DELETE RESTRICT).
Sonst ist es halt so ein Art Garbage Collector, der hinter dir aufräumst (ON DELETE CASCADE).
Die entfalten ihre volle Wirkung aber nicht bei select-Abfragen sondern nur bei Abfragen, die etwas ändern (insert,update,delete).

Ich würd am Anfang die Foreign Keys einfach weglassen. Das macht es einfacher und du lernst die Fallstricke bei DBs.

 

[mambokurt]

Foreign Keys sind mehr als nice to have, sie schützen dich vor Dummheiten wie Datensätze, die die Integrität der DB verletzten würde, einzufügen oder welche, die du brauchst zu löschen. (ON DELETE RESTRICT).

Das fällt für mich unter 'nice to have' Klar, wenn es sinn ergibt kann und sollte man sie verwenden, aber beim TE hatte ich einfach das Gefühl dass er sich etwas zu stark darauf versteift. Ich glaube nicht, dass er Anfangs mit mehr als 20 Tabellen hantiert, und gerade wenn man die alle selbst angelegt hat ist die Sache eigentlich noch ohne FKs zu handlen. Anlegen kann er sie ja zur Not immer noch

 

[Daaron]

Foreign Keys sind mehr als nice to have, sie schützen dich vor Dummheiten wie Datensätze, die die Integrität der DB verletzten würde

Foreign Keys sind so unwichtig, dass unter MySQL immer noch relativ oft MyISAM statt InnoDB verwendet wird, ohne das es zu negativen Nebeneffekten kommt. Man muss halt mehr Hirnschmalz in die eigene Programmlogik stecken, weil man es nicht aufs RDBMS abwälzen kann.

 

[mambokurt]

Naja, so würde ich das jetzt auch nicht sagen. Bei großen Projekten mit wechselnden Entwicklern macht das spätestens Sinn, das vermeidet halt dass jemand der die Abhängigkeiten nicht kennt Satz a) löscht Satz b) aber nicht. Den Überblick hat man als Neuer bei 100 Tabellen einfach kaum. Auf die Art weiß man auch eher, wie die Tabellen querverknüpft sind. Einfach das Create Statement angeschaut und gut.
Aber um das mal so zu sagen: der TE macht sich gerade Gedanken über Airbags und hat noch nichtmal ein Lenkrad in seinem Feuersteinauto. An der Stelle der Lernkurve halte ich FKs eigentlich wirklich für Kinkerlitzchen. Dann lieber erstmal Selects, Subselects, Joins, Unions und die Tücken des Group und Order gelernt, das ist schon eher das tägliche Brot. Ein Create Table Statement(Geschweige denn Constraints) müßte ich heute noch nachschlagen, so selten habe ich das bisher gebraucht...

 

[Daaron]

Bei großen Projekten sollte man dokumentieren. Eine Datenstruktur darzustellen ist echt kein Hexenwerk. Wozu gibts z.B. UML?

 

[mambokurt]

Das funktioniert wenn du es von Anfang an machst. Wenn du das für ein fast fertiges Projekt machst siehts aber schon ganz anders aus
Erklär mal deinem Chef, dass du die nächsten Tage UMLs malst, die Reaktion wird irgendwo zwischen 'muß das wirklich jetzt sein?' und 'gehts noch?' liegen ^^

 

[chuya194]

Danke für die Grundlagenstunde! Ich muss mir noch einiges anschauen!
Bin aber bei meinem Problem weitergekommen!!

 

[Daaron]

Erklär mal deinem Chef, dass du die nächsten Tage UMLs malst, die Reaktion wird irgendwo zwischen 'muß das wirklich jetzt sein?' und 'gehts noch?' liegen ^^

Wenn er so reagiert sag ich ihm: Entweder, wir bringen hier jetzt Ordnung rein, oder wir verlieren jedes Mal massig Zeit, wenn wir das Projekt wieder wegen irgend etwas anfassen.

Alles, was über ein paar Dutzend Zeilen hinaus geht (oder anderweitig selbsterklärend ist), sollte immer dokumentiert werden. Sonst guckt sogar der Verfasser nach einem halben Jahr wies Schwein ins Uhrwerk.