SQL MySql kürzel

[Sasku]

Hey Leute,

ich wollte fragen ob es in MySql möglich ist die kürzel wie in SQL für Tabellennamen zu verwenden?

select g.* from gptransferplan g, gpperson p, gpjob j 
where p.isInstructor = 'no' and 
p.isAdvisor = 'no' and 
j.InstructorID = 31762 and j.JOBID = p.JOBID ;

also so wie es hier gemacht wurde .. denn irgendwie funktioniert das nicht bzw. liefert keine Datensätze... und ich weis nicht wieso.. da dachte ich ob es eventuell an den kürzeln liegen könnte?

 

[NullPointer]

Doch, MySQL kann das. Allerdings fällt mir an deiner Anfrage auf, dass du zwar Zeilen aus g selektieren willst, die where-Bedingung sich aber nur auf p und j bezieht. Irgendwo fehlt da eine Bedingung der Form "where g.<Feldname> = ...".

 

[Umbel]

Ich glaub du haust da was durcheinander ... die Syntax sieht mir aus wie ein missglückter JOIN-Versuch

 

[mental.dIseASe]

Wenn das Statement keine Ergebnisse zurückliefert, dann liegt es eher nicht an den Kürzeln. Versuch erstmal, dir darüber klar zu werden, was du wie verknüpfen willst. Falls du nicht weiterkommst, mal dir einzelne Tupel aufs Papier und verjoine die. Ich kenne mich mit MySQL nicht aus, aber auch da sollten sich Komma-Joins vermeiden lassen. Die Beziehung zwischen p und j sieht bspw. wie ein INNER JOIN aus.

 

[Drexel]

Je nach Datenbanksystem spricht gegen Komma-Joins nichts. Der Query Optimizer löst das schon richtig auf. Wie sich MySQL verhält weiß ich nicht.

 

[Sasku]

Ich glaub du haust da was durcheinander ... die Syntax sieht mir aus wie ein missglückter JOIN-Versuch

... naja es ist kein missglückter Versuch .. es ist nunmal die einzige Variante ^^ habe jetzt die letzte Bedigung rausgeworfen und es hat funktioniert ..

Ergänzung (2. April 2015)

Doch, MySQL kann das. Allerdings fällt mir an deiner Anfrage auf, dass du zwar Zeilen aus g selektieren willst, die where-Bedingung sich aber nur auf p und j bezieht. Irgendwo fehlt da eine Bedingung der Form "where g.<Feldname> = ...".

okey gut ... naja ich habe jetzt die letzte where Bedigung rausgeworfen (and j.JOBID = p.JOBID) und es funktioniert .. ^^

ich möchte hier einen Versetzungsplan anzeigen lassen der wiederum abhängig von dem Azubi und von der Ausbildernummer ( hier als Bsp. 31762 ) ist .. und da ich im versetzungsplan ( gptransferplan g ) nicht nach irgendwas selektieren möchte ... außer eigentlich nach dem Ausbilder passt das dann schon ^^

 

[Faust2011]

Je nach Datenbanksystem spricht gegen Komma-Joins nichts. Der Query Optimizer löst das schon richtig auf. Wie sich MySQL verhält weiß ich nicht.

Ja, das stimmt. Es ist jedoch trotzdem gut vor Augen zu haben, was man denn möchte und nicht alles über einen Full-Join zu formulieren. Das machen nur Anfänger

 

[Daaron]

Kommt ganz darauf an, wo eher der Engpass liegen wird: Bei der DB-Last oder bei der Speicherauslastung.

Beispiel: Ich habe News-Beiträge in einer Tabelle, und Autoren in einer anderen. Jetzt hat aber jeder Beitrag einen Autor, referenziert über dessen ID.
Wenn ich jetzt den Beitrag anzeigen will, macht es dann wirklich Sinn, nacheinander 2 Querys abzufeuern, jeweils für die reine News und die reinen Autor-Daten? Für die paar Fälle, wo ich den Autor nicht benötige, hab ich nur etwas RAM verschwendet. Für alle anderen habe ich aber einen separaten Query für den Autor gespart.

Wenn du mit ORM arbeitest, landest du immer irgendwann vor der Frage: Eager oder lazy loading? Oft gewinnt eager, weil RAM eben billiger ist als DB-Queries.

 

[Faust2011]

Zuerst nen Full-Join (braucht viel Speicher und dauert lange) um anschließend über eine Projektion die Daten wieder auszudünnen? Dann doch gleich einen Outer-Join. Und das kriegt auch ein ORM hin.

 

[NullPointer]

ich möchte hier einen Versetzungsplan anzeigen lassen der wiederum abhängig von dem Azubi und von der Ausbildernummer ( hier als Bsp. 31762 ) ist .. und da ich im versetzungsplan ( gptransferplan g ) nicht nach irgendwas selektieren möchte ... außer eigentlich nach dem Ausbilder passt das dann schon ^^

So wie ich das sehe, selektierst du aber wirklich nach gar nichts, d.h. deine Query macht dasselbe wie

SELECT * FROM gptransferplan

 

['cuda]

Ja, das stimmt. Es ist jedoch trotzdem gut vor Augen zu haben, was man denn möchte und nicht alles über einen Full-Join zu formulieren. Das machen nur Anfänger

Was ist für Dich ein Full-Join?

Ein Beispiel:

select
	a.news_meldung
	, b.author
from
	news_meldungen a
	, autoren b
where
	a.author_id = b.id
	and lower(b.author) = 'meyer';

"Gib mir alle Newsmeldungen vom Kollegen Meyer".

Es gäbe grundsätzich zwei Wege diese Querry auszurühren:
1. HashJoin von meldungen und autoren mit anschliessendem Filtern nach Meyer
2. Holen der id aus der Authorentabelle, dann ein RangeScan auf die Meldungen.

@NullPointer:

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

Die Querry von oben nochmal, aber anders formatiert:

select 
	g.* 
from 
	gptransferplan g
	, gpperson p
	, gpjob j 
where 
	p.isInstructor = 'no' 
	and p.isAdvisor = 'no' 
	and j.InstructorID = 31762 
	and j.JOBID = p.JOBID;

Das (p.isInstructor = 'no' and p.isAdvisor = 'no' and j.InstructorID = 31762) ist ein Filter jeweils auf p und g, das (j.JOBID = p.JOBID) ist join auf j+p, soweit alles gut. Nur, es ist noch die Tabelle (g) im Spiel, die aber weder gefiltert noch gejoint wird. Ist an und für sich okay. Das Statement ist trotzdem korrekt, aber das, was hier rauskommt ist ein kartesisches Produkt aus der Tabelle (g) und dem ResultSet des restlichen SQLs. Angenommen Tabelle (g) hat 100 Datensätze und Abfrage von (j und p) liefert 40 Datensätze zurück, kommt der Inhalt der Tabelle (g), aber 40 Mal, also 4000 Datensätze.

Wegen (select g.*): An und für sich auch kein Problem. Man muss nur im Hinterkopf behalten, dass je nach dem, was für Datentypen da kommen, wird das ResutlSet unterschiedlich gelesen. Wenn da nur VARCHAR und NUMBER und DATE und sowas drin ist, alles okay, es wird chunk-weise durchiteriert, ausser dass die Menge an Daten vielleicht unnötig ist, wenn nur wenige Spalten gebraucht werden. Sollte da aber eine BLOB oder CLOB Spalte drin sein, werden die Datensätze einzeln geholt. Und das ist richtig hässlich.

@umbel: Wenn man keine Ahnung hat und so... INNER JOIN, OUTER JOIN, JOIN ist Ansi-SQL. Das Verknüpfen der Tabellen in der WHERE-Clause ist genau so zulässig und wird sehr oft gemacht, beispielsweise bei Oracle.

@Sasku: Ja, es ist möglich. Diese Kürzel heißen übrigens Aliase.

 

[Drexel]

Das habe ich auch schon probiert zu sagen "Komma-Joins" kenne ich auch von absoluten Profis im Oracle Bereich...

 

['cuda]

Das ist ja das Geile bei Oracle, es gibt keinen Unterschied zwischen Join- und Filterbedienungen. Oracle ist (für mich) das bevorzugte RDBMS, wird immer eingesetzt, wenn es möglich ist.

 

[Faust2011]

@'cude: Ich habe in Richtung Kreuzprodukt gedacht. Durch Deine Darstellung finde ich die ganze Thema hier super aufbereitet.

Was man bei der Analyse von SQL-Statements nie vergessen sollte: der konkrete Ausführungsplan eines Datenbanksystems lässt sich nie im Voraus erschließen. Der kann immer anders sein, da er z. B. auch von den Indizes (bzw. deren Aktualität) abhängt. Auch der aktuelle Füllstand der Tabellen spielt eine Rolle.

 

[mental.dIseASe]

Was der Optimizer letztlich macht ist die eine Sache, aber ich finde es als Mensch schwer zu lesen und etwas kacke wartbar, wenn Joins als Filter geschrieben werden. Wir würden dafür auch was hinter die Löffel bekommen, wenn das bei uns einer macht. Deswegen wird nur verkomma't, wenn das auch tatsächlich so gewollt ist, ansonsten so explizit wie möglich verjoint. DBMS ist bei uns übrigens auch Oracle.

 

['cuda]

@'cude: Ich habe in Richtung Kreuzprodukt gedacht. Durch Deine Darstellung finde ich die ganze Thema hier super aufbereitet.

Was man bei der Analyse von SQL-Statements nie vergessen sollte: der konkrete Ausführungsplan eines Datenbanksystems lässt sich nie im Voraus erschließen. Der kann immer anders sein, da er z. B. auch von den Indizes (bzw. deren Aktualität) abhängt.

Doch, tut es, sogar relativ einfach. Man muss lediglich die Selektivität kennen und das darausresultierende Größenverhältnis der Tabellen.

Indexes allein bringen rein gar nichts und was ist eine "Aktualität des Indexes"? Sowas, wie "Aktualität des Indexes" gibt es nicht, entweder ist das Ding da oder eben nicht.

Die Wichtigsten Parameter für den Ausführungsplan sind (reihenfolge ist irrelevant):
1. sind die Spalten, auf die gefiltert und gejoint wird, indexiert?
2. wie sehen die Histogramme aus
3. wie selektiv ist das Prädikat, mit dem in die Tabelle reingegriffen wird
4. kann eine Abfrage rein aus dem Index bedient werden oder muss zwingend auf die Tabelle zugegriffen werden (aus dem Beispiel mit Newsmeldungen: man kann einen Index erstellen, der autor_id und author beinhaltet, damit spart man sich den Tabellenzugriff)
5. wie ist das Größenverhältnis der Tabellen
6. ist der Optimizer eingestellt: first_rows vs. all_rows.

Auch der aktuelle Füllstand der Tabellen spielt eine Rolle.

Nein, tut es nicht, solange die Spalte über die reingegriffen wird, einen Index hat.

Was der Optimizer letztlich macht ist die eine Sache, aber ich finde es als Mensch schwer zu lesen und etwas kacke wartbar, wenn Joins als Filter geschrieben werden.

Schwer zu lesen? Also ich erkenne einen Filter und einen Join auf den ersten Blick. Und was soll daran "kacke wartbar"?

Ansi-SQL macht nur dann Sinn, wenn man versucht datenbankunabhängig (bzw. DB-übergreifend) zu entwickeln, aber das ist eh utopisch. Es gibt keinerlei Gründe bei Oracle Ansi-SQL zu verwenden. Es gibt nur einen UseCase, der mir so spontan einfällt, wo man mit Oracle-SQL nicht weiterkommt: ein zweifacher OUTER JOIN aus eine Tabelle.

Wir würden dafür auch was hinter die Löffel bekommen, wenn das bei uns einer macht. Deswegen wird nur verkomma't, wenn das auch tatsächlich so gewollt ist, ansonsten so explizit wie möglich verjoint. DBMS ist bei uns übrigens auch Oracle.

Absoluter Schwachsinn, aber macht nur. Unsere Entwickler kriegen eins auf den Sack, wenn sie für IDs Integer nehmen und einer auf die Idee kommt Ansi-SQL zu hacken, wenn es nicht unbedingt (Beispiel von oben) notwendig ist. Wenn ich ein bestimmtes RDBMS habe, dann entwickle ich bitte auch genau für dieses.

 

[Faust2011]

Doch, tut es, sogar relativ einfach. Man muss lediglich die Selektivität kennen und das darausresultierende Größenverhältnis der Tabellen.

Ja, das muss man kennen. Und in meiner Annahme bin ich davon ausgegangen, dass diese Kenntnis nicht vorliegt. Ich hatte mal den Fall, wo ich gefragt wurde, ob ich die Laufzeit eines bestimmten SQL-Statements abschätzen kann. Und dabei lag das genannte genau nicht vor. Wie so oft: 'it depends...'.

Indexes allein bringen rein gar nichts und was ist eine "Aktualität des Indexes"? Sowas, wie "Aktualität des Indexes" gibt es nicht, entweder ist das Ding da oder eben nicht.

War auf einem älteren DB/2 System, dass da was auseinandergelaufen ist

 

[mental.dIseASe]

Krass, wie schnell manche Leute ausfallend werden. Ich klinke mich dann mal hier aus.

 

[yxcv]

Das habe ich auch schon probiert zu sagen "Komma-Joins" kenne ich auch von absoluten Profis im Oracle Bereich...

Zumindest sind es Profis dich glauben zu lassen, Profis zu sein.
"Komma-Joins" nutzen nur Leute die es nicht besser können.

Das ist ja das Geile bei Oracle, es gibt keinen Unterschied zwischen Join- und Filterbedienungen.

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.

 

[Faust2011]

Ja, so habe ich es auch bisher verstanden. Vielleicht kann jedoch ein modernes DBMS den Join optimieren, statt ein (komplettes) Kreuzprodukt der verknüpften Tabellen (a.k.a. Full Join) zu erstellen und erst dann die Ergebnismenge gemäß dem WHERE einzugrenzen.