SQL MySql kürzel

['cuda]

Doch den gibt es!
Wie die Namen schon treffend bezeichnen, stehen im:
JOIN = hier steht mit welchen Spalten die beteiligten Tabellen grundsätzlich
(und unabhängig vom WHERE) verknüpft sind.

WHERE = nachdem per JOIN die Tabellenverknüpfung definiert wurde,
wird per WHERE die Ergebnismenge eingegrenzt.
Also nach bestimmten, Zahlen, Worten, etc suchen.

Wer sich nicht daran hält, schreibt unübersichtlichen, langsamen, inkompatiblen Mist.

So ein Bullshit.

Mit was soll es bitte kompatibel sein? Wenn ich für Oracle entwickle, dann ist es mir sowas von schnurzegal, ob es auf DB2, Informix, SapDB oder sonstwas läuft. Und dem Oracle ist es egal, ob ich die Tabellen mit JOIN zusammenjoine und dann filtere oder alles in der WHERE-Clause schreibe. Wichtig ist, was der Optimizer damit macht und wie dann der Ausführungsplan aussieht.

Vielleicht ist es bei MySQL oder MS SQL oder sonstwas von Bedeutung ist, keine Ahnung. Aber diese Behauptung alle RDBMS zu übertragen ist FALSCH!!!

@Faust: Dem ist es eben nicht so. Ob ein RDBMS ein "komplettes Kreuzprodukt" aus Tabellen macht, hängt von ganz anderen Faktoren ab und eben NICHT davon, ob ich die Tabellen erstmal JOINe oder alles in der WHERE landet.

Willst Du ein Beweis dafür? Kann ich Dir gern liefern.

 

[yxcv]

So ein Bullshit.

Mit was soll es bitte kompatibel sein? Wenn ich für Oracle entwickle, dann ist es mir sowas von schnurzegal, ob es auf DB2, Informix, SapDB oder sonstwas läuft Und dem Oracle ist es egal, ob ich die Tabellen mit JOIN zusammenjoine und dann filtere oder alles in der WHERE-Clause schreibe. .

Da das ist Kleinkind-Sandkastendenken und mag für deine kleinen Micky Maus Projekte zutreffen.
Für reale Großprojekte ist Kompatibilität für die langfristige Nutzung extrem wichtig,
dazu gehören auch Code Conventions!

Von der schlichten Schulaufgabe bis zur professionellen Anwendung
spricht alles dafür (u.a. Übersichtlich, leicht verständlich, kompatibel und schnell)
sich an die von mir genante Regel zu halten
und nicht ein sinnvoller Grund dagegen (außer die Anwender abhängig vom Programmierer zu machen).

Wichtig ist, was der Optimizer damit macht und wie dann der Ausführungsplan aussieht.

Wie geschrieben spielt der Programmspiel eine sehr wichtige Rolle - der Code muss also auch übersichtlich sein.
Der Optimizer kann nur Vermutungen anstellen was gemacht werden soll.
Gegen einen erfahren Datenbankadmin, der weiß was er da entwickelt, ist der Optimizer klar unterlegen.

 

[mambokurt]

So ein Bullshit.

Mit was soll es bitte kompatibel sein? Wenn ich für Oracle entwickle, dann ist es mir sowas von schnurzegal, ob es auf DB2, Informix, SapDB oder sonstwas läuft. Und dem Oracle ist es egal, ob ich die Tabellen mit JOIN zusammenjoine und dann filtere oder alles in der WHERE-Clause schreibe. Wichtig ist, was der Optimizer damit macht und wie dann der Ausführungsplan aussieht.

Hmm, na dann viel Spaß bei Statements wo du 10+ Tabellen aufeinander joinst. Bei JOIN XYZ ON siehst du auf einen Blick, welche Tabelle auf welche über welche Felder gejoined wird. Bei der Kommasyntax darfst du da erstmal 10 Zeilen weiter unten im Where rumsuchen, am Besten stehen da die Joinbedingungen nicht einmal hintereinander sondern schön übers Where verteilt. Leider tendieren Statements dazu, mit der Zeit zu wachsen. Das auf die JOIN ON umzuschreiben wenn nach und nach 2,3,4,5 Tabellen dazukommen hängt sich keiner ans Bein.

Wenn ich mal schnell eine Abfrage zusammenzimmere und Zeit sparen will, finde ich das noch halbwegs legitim, ansonsten gibt es IMHO _keinen_ Grund für Kommajoins. Die sind unübersichtlich, fehleranfällig und damit schwer wartbar. Wenn bei uns einer mit so einem Statement wie der TE ankommen würde, würde ich ersteinmal Nackenschläge verteilen

 

[Faust2011]

Das ist BullShit, dass sie dasselbe macht wie Deine Querry.

Absoluter Schwachsinn, aber macht nur.

So ein Bullshit.

Könntest Du Dich bitte in Deiner Ausdrucksweise etwas zurücknehmen? Du kannst Dich hier in dem Thema sehr gut einbringen und es kommt eine Diskussion zu Stande, was ich sehr schätze, aber es gibt keinen Grund, andere Meinungen so durch den Dreck zu ziehen... ich hoffe, dass das nicht auch der Umgangston in Deinem Büro ist

 

[Drexel]

Da das ist Kleinkind-Sandkastendenken und mag für deine kleinen Micky Maus Projekte zutreffen.
Für reale Großprojekte ist Kompatibilität für die langfristige Nutzung extrem wichtig,
dazu gehören auch Code Conventions!

Deine Denke halte ich auch für sehr engstirnig. Du kennst anscheinend nur Projekte aus Deinem Umfeld und kannst Dir nicht vorstellen, dass auch andere gibt, die aus Deinem Erfahrungsschatz nicht abschließend beurteilbar sind. Wenn es in Projekten darum geht, das letzte bißchen Performance rauszuholen kommst Du eine Optimierung auf das jeweilige DBMS gar nicht drum rum. Da ist Dir die Kompatibilität dann ziemlich egal, Bei einem Systemwechsel müssen dann wieder neue Optimierungen vorgenommen werden.

Ich frage mich immer, wie man sich anmaßen kann sein, seine Wissen und seine Erfahrung für das einzig Wahre zu halten... Es soll evtl. auch Dinge geben, die von den eigenen Erfahrungen abweichen und die man nicht zu 100% beurteilen kann.

 

[yxcv]

Deine Denke halte ich auch für sehr engstirnig. Du kennst anscheinend nur Projekte aus Deinem Umfeld und kannst Dir nicht vorstellen, dass auch andere gibt, die aus Deinem Erfahrungsschatz nicht abschließend beurteilbar sind. Wenn es in Projekten darum geht, das letzte bißchen Performance rauszuholen kommst Du eine Optimierung auf das jeweilige DBMS gar nicht drum rum. Da ist Dir die Kompatibilität dann ziemlich egal, Bei einem Systemwechsel müssen dann wieder neue Optimierungen vorgenommen werden.

Selbstverständlich gibt es je DBMS unterschiedliche Optimierungsmöglichkeiten.

Der von mir genannte Aufbau ist jedoch eine Grundvorrausetzung dafür - unabhängig vom jeweiligen (relationalen) DBMS.
Genauso wie ein Axium in der Mathematik für logische Beweise.