verstehe JOIN nicht
Jeena Paradies
- datenbank
0 Rouven0 Jeena Paradies
0 Ilja
Hallo,
Ok ich habe hier eine Aufgabenstellung, die wohl mit JOIN gelöst werden kann, es handelt sich um eine MySQL Datenbank. Jetzt habe ich mir mal die Doku durchgelesen und verstehe immer noch nur Bahnhof.
Ich habe zwei Tabellen, die voneinander abhängig sind.
id | mannschaft_a | mannschaft_b | zustand | tor_a | tor_b | liga_id | startzeit
id | liganame
In der Tabelle Spiele sind ganz viele Einträge, von Fussballspielen. Damit ich nicht bei jedem Spiel den Namen der Liga in der Spieletabelle drinn stehen habe, da sie sich immer wiederholen, habe ich für die Namen der Ligen eine Extra Tabelle gemacht. Dabei habe ich bei den Spielen beim jeweiligen Spiel in liga_id die zugehörige id aus der Tabelle Ligen reingemacht (normalisierung heißt das glaube ich, oder?). Jetzt möchte ich die Spiele ausgeben, aber nicht einfach wahllos. Die Spiele sollen erst alphabetisch nach zugehörigem Ligennamen und dann innerhalb der gleichen Ligennamen nach startzeit.
Das Problem ist, dass ich nicht weiß wie ich erst nach Ligennamen alphabetisch sortieren lasse ... Kann mir da jemand auf die Sprünge helfen?
Grüße
Jeena Paradies
Hi,
sortiere nicht im voraus nach Liganamen, lasse erst über den join alles ermitteln und sortiere dann nach
liganame, startzeit, ...
MfG
Rouven
Hallo,
sortiere nicht im voraus nach Liganamen, lasse erst über den join alles ermitteln und sortiere dann nach
liganame, startzeit, ...
Ja das habe ich schon verstanden, nur verstehe ich nicht wie ich das konkret per JOIN anwende, bzw. was JOIN eigentlich macht. Deshalb weiß ich nicht was es bedeutet "über join alles ermitteln lassen".
Grüße
Jeena Paradies
Hi,
Ja das habe ich schon verstanden, nur verstehe ich nicht wie ich das konkret per JOIN anwende,
_exakt_ so wie ohne Join. Ein Join hat keinerlei Einfluss auf die Sortierung.
bzw. was JOIN eigentlich macht.
Es spezifiziert die Bedingung, welche die Datensätze einander zuordnet.
Cheatah
Der Join macht nichts anderes als die beiden Tabellen zusammenzuführen und dabei ein bestimmtes Kriterium anzulegen. Ein INNER JOIN beispielsweise verlangt, dass alle in ON angegebenen Bedingungen erfüllt werden. In deinem Fall wäre das ein
SELECT...
FROM
ligen INNER JOIN spiele
ON ligen.id = spiele.liga_id
Das ergibt das Bild so, als hättest du direkt alles in einer Tabelle gespeichert.
MfG
Rouven
Hallo,
SELECT...
FROM
ligen INNER JOIN spiele
ON ligen.id = spiele.liga_id
Das ergibt das Bild so, als hättest du direkt alles in einer Tabelle gespeichert.
Oahaaa das ist also gar nicht so kompliziert wie ich mir das vorgestellt habe? Ich dachte wunder was der JOIN alles macht, jetzt verstehe ich aber endlich. Vielen vielen Dank jetzt bin ich ein großes Stück vorwärts gekommen. Ohne das Beispiel hätte ich das nie kappiert :-) Dann auf auf an die Arbeit ;-).
Grüße
Jeena Paradies
Hallo Jeena,
Oahaaa das ist also gar nicht so kompliziert wie ich mir das vorgestellt habe? Ich dachte wunder was der JOIN alles macht, jetzt verstehe ich aber endlich. Vielen vielen Dank jetzt bin ich ein großes Stück vorwärts gekommen. Ohne das Beispiel hätte ich das nie kappiert :-) Dann auf auf an die Arbeit ;-).
Du darfst auch gern noch diesen Archivbeitrag von mir durchlesen.
Freundliche Grüße
Vinzenz
yo,
als ergänzung zu dem, was schon gesagt wurde, ist ein JOIN letztlich nichts anderes als die verbindung zweier, bzw. mehrer tabellen. sind keine bedingungen angegeben, werden alle datesnätze der tabelle a mit allen datensätzend der tabelle b verbunden. man spircht dann von einem karthesischen produkt der tabellen.
da man nun aber nicht immer alle datensätze der tabelle a mit allen datensätzen der tabelle b verknüpft haben will, gibt es unterschiedliche arten, wie man die beiden tabellen miteinander verbinden kann. leider geben selbst fachbücher nicht immer die richtigen fachbegriffe dafür wieder und die namen der verschiedenen join-arten werden munter durcheinander gewürfelt.
vielleicht sollte man hier mal bei seflhtml eine kleine extra seite veröffentlichen, welche die JOINS beim richtigen namen nennt und diese auch erklärt. wäre doch mal ein vorschlag. man könnte diese seite dann einfach als antwort verlinken, da fragen über den JOIN doch des öfteren auftauchen.....
Ilja
Die Sache mit dem Artikel finde ich eine gute Idee. Ich verspreche nicht, dass ich einen fertig bekomme, aber ich werde zumindest mal anfangen etwas zusammenzutragen.
MfG
Rouven
Hallo Ilja,
vielleicht sollte man hier mal bei seflhtml eine kleine extra seite veröffentlichen, welche die JOINS beim richtigen namen nennt und diese auch erklärt. wäre doch mal ein vorschlag. man könnte diese seite dann einfach als antwort verlinken, da fragen über den JOIN doch des öfteren auftauchen.....
Für SELFHTML 9 ist sowieso ein Datenbankkapitel geplant, aber bis das mal fertig wird, wird's noch einige Zeit dauern, ich halte das also für eine gute Idee. Hat irgendjemand hier Lust? ;-)
Viele Grüße,
Christian
Hallo Christian,
Für SELFHTML 9 ist sowieso ein Datenbankkapitel geplant, aber bis das mal fertig wird, wird's noch einige Zeit dauern, ich halte das also für eine gute Idee. Hat irgendjemand hier Lust? ;-)
da ich im Augenblick krank bin, hätte ich die Zeit dafür. Und Lust auch. Ich könnte sofort loslegen. Die Frage, die sich mir stellt: "Tipps und Tricks" oder "Feature-Artikel".
Freundliche Grüße
Vinzenz
Hallo Vinzenz,
da ich im Augenblick krank bin,
Gute Besserung!
Ich könnte sofort loslegen.
Prima! :-)
Die Frage, die sich mir stellt: "Tipps und Tricks" oder "Feature-Artikel".
Das richtet sich denke ich nach dem Umfang, der am Ende rauskommt und evtl. der Art, wie Du's geschreiben hast. Nimm Dir die Beispieldatei für Tipps&Tricks und schreib drauf los - und falls es länger wird, wird einfach Tipps&Tricks durch Feature-Artikel ersetzt und bei den Feature-Artikeln veröffentlicht.
Viele Grüße,
Christian
Hallo Christian,
Gute Besserung!
danke, kann ich gebrauchen.
Ich könnte sofort loslegen.
ist zu ersetzen durch: Ich lege los :-)
Das richtet sich denke ich nach dem Umfang, der am Ende rauskommt und evtl. der Art, wie Du's geschreiben hast. Nimm Dir die Beispieldatei für Tipps&Tricks und schreib drauf los - und falls es länger wird, wird einfach Tipps&Tricks durch Feature-Artikel ersetzt und bei den Feature-Artikeln veröffentlicht.
Ok, so werde ich es angehen.
Freundliche Grüße
Vinzenz
Hallo,
ist zu ersetzen durch: Ich lege los :-)
Sehr cool, vielen Dank schon jetzt mal für deine Mühe, ich werde den Artikel bestimmt gut gebrauchen können in der Zukunft, versuch aber auch so zu schreiben dass Datenbank nixblicker wie ich das auch verstehen ;-).
Grüße
Jeena Paradies
Hallo Vinzenz,
ist zu ersetzen durch: Ich lege los :-)
Klasse. :-)
Viele Grüße,
Christian
yo,
ist zu ersetzen durch: Ich lege los :-)
falls du unterstüzung brauchst oder nur jemanden, der mal quer liest, ich würde meine hilfe anbieten, obwohl ich im moment nicht all zuviel zeit habe. in 2 wochen sieht es dann schon besser aus.
und nicht vergessen, unser lieblingsthema mit aufnehmen, mysql und gruppierungen, falls es über JOINS hinausgeht.den link könnte man nämlich hier auch gut gebrauchen....
Ilja
Hi!
Nach meiner Kurzankündigung heute Nachmittag habe ich mich tatsächlich mal hingesetzt und was zusammengeschrieben. Es ist im Prinzip ein Kurzbeispiel, an dem einfach die JOIN-Möglichkeiten mal durchgesprochen werden.
und nicht vergessen, unser lieblingsthema mit aufnehmen, mysql und gruppierungen, falls es über JOINS hinausgeht.den link könnte man nämlich hier auch gut gebrauchen....
Davon ist in der Kürze der Zeit nichts erwähnt...
Schaut euch den Artikel mal an und entscheidet, ob da überhaupt was von verwendet werden soll oder was...
http://tsdnet.ts.funpic.de/joins_leicht_gemacht.htm
Guckt bitte vor allem nochmal in Hinblick auf Allgemeingültigkeit vs. DBMS drüber. Ich habe fast nur Erfahrung mit der DB2 und die frisst so einiges bei JOINs...
MfG
Rouven
Hallo Freunde des gehobenen Forumsgenusses,
Schaut euch den Artikel mal an und entscheidet, ob da überhaupt was von verwendet werden soll oder was...
http://tsdnet.ts.funpic.de/joins_leicht_gemacht.htm
Also ich bin bei Datenbanken noch totaler Anfänger, ich habe im Moment nur eine Liste mit 200.000 Wörtern,
in denen ich nach Einträgen suche, die ein bestimmtes Teilwort enthalten.
Gehöre ich mit diesen Vorkenntnissen zur Zeilgruppe?
Ich finde den Artikel jedenfalls sehr gut, habe aber zwei Fragen:
1. Warum rät das MySQL-Handbuch von der Verwendung von right joins ab?
2. Was mache ich wenn ich mehr als zwei Tabellen auf einmal verknüpfen will?
Gruß
Alexander Brock
Hallo,
Ich finde den Artikel jedenfalls sehr gut, habe aber zwei Fragen:
- Warum rät das MySQL-Handbuch von der Verwendung von right joins ab?
OK, das schlag ich nach, hab gerade nur auf die Schnelle was von nur wegen der Kompatibilität implementiert gelesen.
- Was mache ich wenn ich mehr als zwei Tabellen auf einmal verknüpfen will?
Kann ich in den allgemeinen Teil nochmal explizit mit aufnehmen, auch mit Beispiel
MfG
Rouven
Hallo Alexander,
Ich finde den Artikel jedenfalls sehr gut, habe aber zwei Fragen:
- Warum rät das MySQL-Handbuch von der Verwendung von right joins ab?
Das MySQL-Handbuch rät nicht direkt von der Verwendung von RIGHT JOIN ab, es rät zur Verwendung von LEFT JOIN anstelle von RIGHT JOIN, da der der SQL-Code portabler bleibt. Es soll DBMS geben, die den RIGHT JOIN nicht unterstützen.
- Was mache ich wenn ich mehr als zwei Tabellen auf einmal verknüpfen will?
Ja, das ist eine gute Frage und nicht mit _einem einzigen_ Beispiel zu erläutern. Kommt dabei mindestens ein OUTER JOIN als Verknüpfung vor, so ist die Ergebnistabelle von der Reihenfolge der einzelnen Verknüpfungen abhängig. Da diese Frage sicherlich bei vielen Projekten auftritt, sollte sie entsprechend ausführlich aufgearbeitet werden. Weiteres von mir zu diesem Thema findest Du in dem von mir verlinkten Posting.
Freundliche Grüße
Vinzenz
Hallo Alexander,
- Was mache ich wenn ich mehr als zwei Tabellen auf einmal verknüpfen will?
unter http://vinzenzmai.vi.funpic.de/tmp/mehrfachjoins.htm habe ich einen ersten Entwurf über die vielen Möglichkeiten hinterlegt, die beim JOINEN von nur drei Tabellen bestehen. Je nach JOIN-Art und Reihenfolge kannst Du 16 verschiedene Resultate erhalten. Aber erschrick nicht, denn die Praxis sieht viel einfacher aus:
Normalerweise hast Du eine genaue Aufgabenstellung, die Du umsetzen willst. Aus dieser Aufgabenstellung resultiert normalerweise gradlinig die richtige Lösung. Aber zu dem Teil bin ich noch nicht gekommen, ich habe heute systematisch alle möglichen Kombinationen (45) systematisch durchgearbeitet, mir den Beweis für die genau 16 verschiedenen Ergebnistabellen erspart, weil mir
a) der Schädel brummt und ich
b) auf externe Unterstützung hoffe.
Im Normalfall hast Du (auf die Schnelle überlegt) 18 mögliche Kombinationen mit einer entsprechend geringeren Anzahl verschiedener Ergebnistabellen. Für Dein beabsichtigtes Ergebnis könnten ggf. mehrere Lösungswege "richtig" sein.
Den Teil gehe ich morgen an! Was meiner Meinung nach wichtiger ist als die systematische Übersicht über alle theoretischen Möglichkeiten ist die praktische Umsetzung einer Aufgabenstellung in die entsprechenden Joins.
Freundliche Grüße
Vinzenz
PS: Die Links in dem von mir verlinkten Doku sind noch nicht bearbeitet, nur der zur SQL-Datei.
Hallo Vinzenz,
Das sieht doch schon sehr schnuckelig aus, wobei ich das jetzt schon zu einem Feature-Artikel ernennen würde, für einen TuT isses dann doch zu theoretisch. Dazu kommt, dass es noch recht Code-lastig ist, aber ich gehe davon aus, dass Du da noch mehr erläutern wirst, wenn es mit dem Kopf wieder aufrecht geht.
Wenn Du soweit bist, melde Dich einfach, z.B. bei mir per Mail, wir werden den Artikel dann noch mal in das interne Review-Verzeichnis stellen, noch mal ein paar scharfe Developer-Augen drüberjagen und ihn dann online stellen.
Tim
echo $begrüßung;
wobei ich das jetzt schon zu einem Feature-Artikel ernennen würde, für einen TuT isses dann doch zu theoretisch.
Warum wird das überhaupt unterschieden? Wenn ich (mal von mir ausgehend) eine Lösung suche, weiß ich nicht, ob jemand dazu ein umfangreiches Essay, oder "nur" einen kurzen Artikel verfasst hat, jemand nur "Wie" oder auch "Warum" erläutert hat. Ich denke, dass mit einem Bereich für beides dem Anwender besser gedient ist, da man dann nicht zweimal suchen muss oder die Lösung im anderen Bereich übersieht.
Wenn es diese Diskussion schon mal gab, bitte ich um Entschuldigung. Ich fand nur </archiv/2004/6/t82836/#m483770> und </archiv/2004/4/t77521/#m447509>.
echo "$verabschiedung $name";
你好 dedlfix,
wobei ich das jetzt schon zu einem Feature-Artikel ernennen würde, für
einen TuT isses dann doch zu theoretisch.Warum wird das überhaupt unterschieden?
Damit Autoren nicht abgeschreckt werden. Nicht jeder hat Lust, einen
vollständigen Artikel zu schreiben. Der Anspruch bei den T&Ts ist geringer.
Da beides von der Suche indiziert wird, sehe ich deine Einwände irgendwie
nicht so recht als relevant.
再见,
克里斯蒂安
echo $begrüßung;
Damit Autoren nicht abgeschreckt werden. Nicht jeder hat Lust, einen
vollständigen Artikel zu schreiben. Der Anspruch bei den T&Ts ist geringer.
Das könnte man durch entsprechende Worte in den Hinweisen an Autoren regeln.
Beispielsweise ist dieses Forum oder die Wikipedia ist auch nicht in lange und kurze Anfragen/Artikel aufgeteilt, damit Autoren ...
Da beides von der Suche indiziert wird, sehe ich deine Einwände irgendwie
nicht so recht als relevant.
Nun ja, nicht jedem liegt es, relevante Suchbegriffe zu formulieren. Besonders wenn die passenden Stichwörter für eine Lösung fehlen, finde ich das Durchsehen von relevanten Themenbereichen hilfreicher.
echo "$verabschiedung $name";
Hallo dedlfix,
Warum wird das überhaupt unterschieden?
Christian hat das schon beantwortet, eine TuT kann man im Prinzip ja auch mal eben schnell per Formular erstellen. Leider hat das nicht wirklich Akzeptanz gefunden. Und developer-intern besteht auch Dissenz über die Trennung. Ein neueres, übersichtliches SELF-Aktuell steht schon länger auf der Liste, ist aber ein größeres Projekt, so dass das noch nicht in näherer Zukunft gemacht werden wird.
Tim
Hallo Tim,
Wenn Du soweit bist, melde Dich einfach, z.B. bei mir per Mail, wir werden den Artikel dann noch mal in das interne Review-Verzeichnis stellen, noch mal ein paar scharfe Developer-Augen drüberjagen und ihn dann online stellen.
hast Du meine Mail bekommen?
Freundliche Grüße
Vinzenz
Hallo Rouven,
Nach meiner Kurzankündigung heute Nachmittag habe ich mich tatsächlich mal hingesetzt und was zusammengeschrieben. Es ist im Prinzip ein Kurzbeispiel, an dem einfach die JOIN-Möglichkeiten mal durchgesprochen werden.
Du hast schnelle und gute Arbeit geleistet.
Schaut euch den Artikel mal an und entscheidet, ob da überhaupt was von verwendet werden soll oder was...
http://tsdnet.ts.funpic.de/joins_leicht_gemacht.htm
Ich finde Deinen Artikel besser strukturiert und insgesamt runder als mein Versuch, der temporär unter http://vinzenzmai.vi.funpic.de/tmp/join.htm zu lesen ist. Dein Beispiel ist gut gewählt: die Begründung, warum jeweils in der anderen Tabelle keine passenden Datensätze vorhanden sind, ist verständlich und nicht wie bei mir eher an den Haaren herbeigezogen. Noch runder wäre der Bogen von der Normalisierung zu den Joins, wenn bei der Normalisierung die gleichen Daten aufgedröselt würden, die nachher beim Join wieder zusammengesetzt werden.
Du motivierst zuerst die Aufteilung in verschiedene Tabellen. Auch das gefällt mir, weil man sonst oft zu hören bekommt: "Was soll das, das steht bei mir doch sowieso alles in einer Tabelle. Ich brauch' das nicht!"
Guckt bitte vor allem nochmal in Hinblick auf Allgemeingültigkeit vs. DBMS drüber. Ich habe fast nur Erfahrung mit der DB2 und die frisst so einiges bei JOINs...
In meinem Artikel verwende ich die gleiche Syntax wie Du, meine Beispiele habe ich mit MySQL 4.1.11 und MS SQL Server 2000 durchgetestet. Sogar MS Access dürfte, soweit ich mich erinnere, bis auf den FULL OUTER JOIN alles hinkriegen. Nach Durchlesen der Doku zu PostgreSQL gehe ich davon aus, dass PostgreSQL ebenfalls alle Deine Statements versteht.
Alexander hat auf jeden Fall einen wichtigen Punkt angesprochen, die Verkettung von JOINs. Ein Beispiel dafür kann man in folgendem Archivthread nachlesen. Das gehört auf jeden Fall dazu, und zwar wieder in einer möglichst breit unterstützten Syntax.
Vielleicht wäre es auch eine gute Idee, das Thema auf zwei Artikel aufzuteilen, einen Grundlagenartikel, der den Einstieg in den JOIN enthält, vom Umfang her wie Dein oder mein Artikel, evtl. sogar etwas abgespeckt und einen darauf aufbauenden zweiten Artikel, der sich z.B. mit den JOINs über mehrere Tabellen, Unterschieden in der von verschiedenen DBMS unterstützten Syntax und ähnlichen weiterführenden Aspekten befasst.
Freundliche Grüße
Vinzenz
Hi,
hmh, mal sehen, wie wollen wir weiter machen. Also einen Teil zu Mehrfachjoins zu schreiben und dabei alle Aspekte von Reihenfolgenproblematik abzudecken kostet mit Sicherheit etwas Zeit, weil man erstmal ein neues, größeres Beispiel braucht. Die Normalisierung am selben Beispiel zu motivieren ist ein Umbau, den man durchaus machen kann.
Ich hab leider die nächsten Tage - zumindest bis Mittwoch - nicht allzuviel Zeit.
MfG
Rouven
Hallo Rouven,
hmh, mal sehen, wie wollen wir weiter machen. Also einen Teil zu Mehrfachjoins zu schreiben und dabei alle Aspekte von Reihenfolgenproblematik abzudecken kostet mit Sicherheit etwas Zeit, weil man erstmal ein neues, größeres Beispiel braucht.
die Zeit hätte ich im Moment, da - wie ich bereits weiter oben im Thread erwähnt habe - ich krankheitsbedingt daheim rumliege oder auch mal sitze. Ich habe (mit einfachen, d.h. leider auch nicht anschaulichen Daten) die Reihenfolgenproblematik begonnen aufzuarbeiten, das ist bereits bei drei Tabellen mehr als die bisherigen Beispiele.
Ein anschauliches Beispiel mit vernünftigen Daten ist auf jeden Fall für das Verständnis besser als eine Serie von Beispielen mit abstrakten, aussagelosen Daten. Mal sehen, die Woche hat ja noch ein paar Tage :-)
Die Normalisierung am selben Beispiel zu motivieren ist ein Umbau, den man durchaus machen kann.
das hört sich sehr gut an.
Freundliche Grüße
Vinzenz
Hallo Ilja,
und nicht vergessen, unser lieblingsthema mit aufnehmen, mysql und gruppierungen, falls es über JOINS hinausgeht.den link könnte man nämlich hier auch gut gebrauchen....
eigentlich hat Dagmar dies bereits in ihrem Artikel Datensätze gruppieren mit SQL bereits getan :-)
Doch auch dort werden die gleichen Leute, die MySQLs Großzügigkeit missbrauchen, den Satz
"... MySQL akzeptiert eine solche Abfrage normalerweise (Ausnahme: im ANSI-Modus), gibt jedoch zufällig einen der möglichen Werte zurück. Da jedoch zufällige Werte genauso nützlich sind wie gar keine Werte ..."
entweder überlesen oder ignorieren. Du kannst ja schlecht ein Beispiel bringen, das deterministisch mit dem gleichen SQL-Statement bei zwei unterschiedlichen Datenbanken, aber gleichem Datenbestand, unterschiedliche Ergebnisse produziert. Dann heißt es wieder: "Wunderbar, bei mir sind die Daten immer in der Reihenfolge xyz, es funktioniert also so, wie ich das haben will!".
Was man bräuchte, wäre ein Beispiel, bei dem mit sehr hoher Wahrscheinlichkeit _nicht_ das Gewünschte rauskommt, obwohl es nach der "Methode" gestaltet ist, die die GROUP-BY-Missbraucher verwenden :-) Und für sowas fehlen mir derzeit die Ideen :-(
Freundliche Grüße
Vinzenz