MySQL Join

[Split1989]

Moin leute

brauche eure hilfe steht gerade einwenig auf dem schlauch

mein datenbank schema sieht wie folgt aus

Cat

ID|NAME
1|Gesundheit
2|Hobby

Sub-Cat

ID|CAT_ID|NAME
1|1|Ernährung
2|1|Bewegung
3|2|Fußball
4|2|Tennis
5|2|Stricken

Packet

ID|SUB_CAT_ID|NAME|BESCHREIBUNG
1|3|Lorem Ipsum1|hier steht dnn irgend was
2|4|Lorem Ipsum2|hier steht dnn irgend was
3|5|Lorem Ipsum3|hier steht dnn irgend was

Lorem Ipsum1 Lorem Ipsum2 und Lorem Ipsum3 haben zwar alle eine andere Sub Kategorie aber ja die gleiche Kategorie

möchte jetet mit dem MYSQL Abfrage alle Packete von Hobby Auslesen (müsste ja dafür über die Sub_cat tabelle gehen) aber irgendwie steht ich gerade auf dem schlauch wie der join auszzusehen hat.

hab das zurzeit sehr drecking duch eine abfrage die in einer schleife ist gelöst.

Kann mir einer eben weiterhelfen?

 

[DonMisery]

Select 
p.NAME, p.BESCHREIBUNG
from packet as p 
left join sub-cat as sc on sc.ID = p.SUB_CAT_ID
left join cat as c on c.ID = sc.CAT_ID
where c.NAME = "Hobby"

So sähe die Abfrage aus, wenn du nach Hobby suchen willst. Ist jedoch nicht getestet, müsste jedoch funktionieren

 

[Split1989]

DANKE funzt super (gehe aber über die ID aber das war ja anhand meines post nicht raus zu lesen)

 

[marac]

join on

Ah, eine Wohltat! Die meisten "Progger" hier in Forum hätten wohl die Tabellen einfach mit Komma hintereinandergeklatscht und die Bedingung in die Where-Klausel gesteckt...

Was ich aber nicht verstehe: Warum baust du einen Left join? Da gehört ein inner join rein, schließlich willst du ja auch aus p nur die Einträge, für die die Join-Bedingung zutrifft. Mit einem Left join würdest du aus p ja alle Einträge bekommen, nur dass die, für die die Join-Bedingung nicht passt, eben mit null-Werten statt mit Werten aus sc ergänzt werden.

 

[DonMisery]

Stimmt, inner Join ist der richtige. Hatte es nur schnell runter getippt und mir nicht weiter gedanken gemacht.

 

[theHacker]

Mit einem Left join würdest du aus p ja alle Einträge bekommen, nur dass die, für die die Join-Bedingung nicht passt, eben mit null-Werten statt mit Werten aus sc ergänzt werden.

Vom Logischen her würd ich sagen, dass da eh Foreign Key Constraints eingesetzt gehören (bedingt InnoDB-Engine). Wenn ein Paket eine Unterkategorie hat, die nicht existiert, sind das korrumpierte Daten; selbiges gilt für eine Unterkategorie, deren Hauptkategorie nicht da ist.
Das wären genau die Fälle, wo der LEFT JOIN zu NULL-Feldern führt.

 

[Deathlyrain]

Ah, eine Wohltat! Die meisten "Progger" hier in Forum hätten wohl die Tabellen einfach mit Komma hintereinandergeklatscht und die Bedingung in die Where-Klausel gesteckt...

Wenn das jetzt auch nicht ganz das Thema dieses threads ist, würde ich gerne hier einhaken. Ich wüsste gerne worin die Vorteile liegen den inner join explizit hinzuschreiben. Denn in der Uni wurde gesagt, dass dieser genauso durchgeführt wird, wenn man im from-Teil mehrere Tabellen angibt und anschließend im where-Teil die join-Bedingung und eben kein wirklicher Unterschied entstehe, da jedes Datenbanksystem eine Optimierung für Anfragen hat.

 

[ice-breaker]

Die Ausführung ist identisch, aber man kann es deutlich besser lesen. Mach mal 5 Joins in einen Query auf beide Varianten und du wirst schnell den Unterschied sehen

 

[marac]

in der Uni wurde gesagt, dass dieser genauso durchgeführt wird, wenn man im from-Teil mehrere Tabellen angibt und anschließend im where-Teil die join-Bedingung und eben kein wirklicher Unterschied entstehe, da jedes Datenbanksystem eine Optimierung für Anfragen hat.

Wie ice-breaker schon geschrieben hat, geht es dabei nicht um die Ausführung an sich, sondern um die Lesbarkeit und Nachvollziehbarkeit. Insbesondere, wenn jemand anders hinterher deinen Code bearbeiten muss, wird er begeistert sein, wenn die Bedingungen kreuz und quer in der Where-Klausel liegen.
Obendrein kann die Schreibweise auch dem Programmierer selbst dabei helfen, Denkfehler bei der Programmierung zu vermeiden, weil er bei jeder Verknüpfung von Tabellen direkt dazuschreibt, wie diese Tabellen denn miteinander zusammenhängen.

 

[ice-breaker]

wie diese Tabellen denn miteinander zusammenhängen.

oder auch direkt im Join schon sinnvolle Eingrenzungen definieren kann:

JOIN table AS b ON(b.xyz_id = a.xyz_id AND b.deleted = 0)

 

[tkiela]

[...] da jedes Datenbanksystem eine Optimierung für Anfragen hat.

Ist das so? Akzeptiert jedes Datenbanksystem, dass die JOINs als SELECTs mit mehreren Tabellen geschrieben werden?
Die Zeit, dass ich mit PostgreSQL zutun hatte, ist leider schon ein wenig her, aber ich glaube mich zu erinnern, dass es da nicht so leicht funktioniert hat.

Vielleicht kann hier noch einmal jemand etwas zu sagen? Interessiert mich.

Grüße.

 

[ice-breaker]

Ja dem ist so. Egal mit was für einem SQL-Query eine Datenbank du füttern wirst, wird diese erstmal den Query in seine Bestandteile zerlegen (Parsing) und dann darauf aufbauend in eine genormte Struktur ablegen, was passieren soll (Quey Execution Plan). Das ganze ist also keine Optimierung, sondern das Aufbauen einer Information, was überhaupt gemacht werden muss.
Das Optimieren findet nachher auf Basis des QEP statt, also in welcher Reihenfolge sollten die Joins abgearbeitet werden und mit welchem Algorithmus (Nested Loop? Hash? Sort-Merge?) [1] und welche Indexe sollten überhaupt genutzt werden? Ist der Index auf A sinnvoller oder der auf B? Welcher hat die meisten unterschiedlichen Werte, wieviele Datensätze geschätzt würde man mit dem Index vorselektieren? Ist ein Fulltable-Scan sinnvoller? Und und und...


PostgreSQL ist in so manchen Dingen MySQL um einiges voraus (Subquery Optimizations, Multicore-Optimierung, Materialization) in anderen Dingen eben auch nicht - aber sei dir sicher, dass PostgreSQL das auch richtig machen wird, das ist eine elementare Funktion eines RDBMS.