Re: UNION und ORDER BY

[Claus Reibenstein]

Volker Englisch schrieb:

> Ich bins schon wieder... Mein Versuch, zwei Tabellen in einer Ausgabe
> zusammenzuführen, sieht nach mehrmaligem Lesen der Doku so aus:
>
> mysql -u "$DBUSER" -p"$DBPW" -t -e"
> (SELECT DATE_FORMAT(Datum, '%d.%m.%Y') as Tag,
> Person COLLATE latin1_german2_ci as 'P',
> DATE_FORMAT(Von, '%H:%i') as Von,
> Text as 'Text/Bis'
> FROM Termine
> WHERE Datum like '$RANGE%')
> UNION
> (SELECT DATE_FORMAT(Datum, '%d.%m.%Y'),
> Person COLLATE latin1_german2_ci,
> DATE_FORMAT(Von, '%H:%i'),
> DATE_FORMAT(Bis, '%H:%i')
> FROM Arbeitszeit
> WHERE Datum like '$RANGE%' AND Person='S')
> ORDER BY 'Tag','Person'" "$DB"

Keine Fehlermeldung? Das wundert mich ein wenig.

So weit ich weiß, müssen (Spalten-, Tabellen-, Alias- etc.)Namen in
Backticks (`) eingeschlossen werden und nicht in Hochkommas (').
Außerdem gibt es in Deiner Ausgabe keine Spalte "Person", sondern nur
eine Spalte "P" (per AS festgelegt). Korrigiere das mal, und dann
schauen wir weiter.

Gruß
Claus

[Axel Schwenke]

Volker Englisch <23C5...@rsli.de> wrote:
> Mein Versuch, zwei Tabellen in einer Ausgabe
> zusammenzuführen, sieht nach mehrmaligem Lesen der Doku so aus:
>
> mysql -u "$DBUSER" -p"$DBPW" -t -e"
> (SELECT DATE_FORMAT(Datum, '%d.%m.%Y') as Tag,
> Person COLLATE latin1_german2_ci as 'P',
> DATE_FORMAT(Von, '%H:%i') as Von,
> Text as 'Text/Bis'
> FROM Termine
> WHERE Datum like '$RANGE%')
> UNION
> (SELECT DATE_FORMAT(Datum, '%d.%m.%Y'),
> Person COLLATE latin1_german2_ci,
> DATE_FORMAT(Von, '%H:%i'),
> DATE_FORMAT(Bis, '%H:%i')
> FROM Arbeitszeit
> WHERE Datum like '$RANGE%' AND Person='S')
> ORDER BY 'Tag','Person'" "$DB"

> Heraus kommt das:
...
> Von dem "ORDER BY" ist irgendwie nicht sehr viel zu erkennen.
> Vielleicht sieht ja jemand von Euch auf Anhieb, was ich falsch mache?

Ja. Du sortierst nach den konstanten Strings 'Tag' und 'Person'.
Was hast du erwartet?

Und selbst wenn das Quoting korrekt wäre, wäre es die Semantik nicht.
ORDER BY für eine UNION kann nur Spalten/Aliase aus dem ersten SELECT
oder (hier IMHO besser) Spalten-Nummern (... ORDER BY 1, 2)

Handbuch lesen! http://dev.mysql.com/doc/refman/5.6/en/union.html


XL

[Bernd Nawothnig]

On 2013-03-14, Claus Reibenstein wrote:
>> Ich bins schon wieder... Mein Versuch, zwei Tabellen in einer Ausgabe
>> zusammenzuführen, sieht nach mehrmaligem Lesen der Doku so aus:
>>
>> mysql -u "$DBUSER" -p"$DBPW" -t -e"
>> (SELECT DATE_FORMAT(Datum, '%d.%m.%Y') as Tag,
>> Person COLLATE latin1_german2_ci as 'P',
>> DATE_FORMAT(Von, '%H:%i') as Von,
>> Text as 'Text/Bis'
>> FROM Termine
>> WHERE Datum like '$RANGE%')
>> UNION
>> (SELECT DATE_FORMAT(Datum, '%d.%m.%Y'),
>> Person COLLATE latin1_german2_ci,
>> DATE_FORMAT(Von, '%H:%i'),
>> DATE_FORMAT(Bis, '%H:%i')
>> FROM Arbeitszeit
>> WHERE Datum like '$RANGE%' AND Person='S')
>> ORDER BY 'Tag','Person'" "$DB"
>
> Keine Fehlermeldung? Das wundert mich ein wenig.
>
> So weit ich weiß, müssen (Spalten-, Tabellen-, Alias- etc.)Namen in
> Backticks (`) eingeschlossen werden und nicht in Hochkommas (').

Da muss nicht nur nichts eingeschlossen werden, in aller Regel sollte
man das sogar ausdrücklich nicht machen. SQL ist nun mal case
insensitive und wenn man das akzeptiert, braucht da auch nichts
gequotet zu werden.

> Außerdem gibt es in Deiner Ausgabe keine Spalte "Person", sondern nur
> eine Spalte "P" (per AS festgelegt). Korrigiere das mal, und dann
> schauen wir weiter.

In der Tat.




Bernd

[Volker Englisch]

Am 14.03.13 schrieb Claus Reibenstein:
> Volker Englisch schrieb:

>
>> mysql -u "$DBUSER" -p"$DBPW" -t -e"
>> (SELECT DATE_FORMAT(Datum, '%d.%m.%Y') as Tag,
>> Person COLLATE latin1_german2_ci as 'P',
>> DATE_FORMAT(Von, '%H:%i') as Von,
>> Text as 'Text/Bis'
>> FROM Termine
>> WHERE Datum like '$RANGE%')
>> UNION
>> (SELECT DATE_FORMAT(Datum, '%d.%m.%Y'),
>> Person COLLATE latin1_german2_ci,
>> DATE_FORMAT(Von, '%H:%i'),
>> DATE_FORMAT(Bis, '%H:%i')
>> FROM Arbeitszeit
>> WHERE Datum like '$RANGE%' AND Person='S')
>> ORDER BY 'Tag','Person'" "$DB"
>
> Keine Fehlermeldung? Das wundert mich ein wenig.

Die hätte es vielleicht gegeben, hätte ich Trottel die Sortierkriterien
nicht in Hochkommas gesetzt :-(

> So weit ich weiß, müssen (Spalten-, Tabellen-, Alias- etc.)Namen in
> Backticks (`) eingeschlossen werden und nicht in Hochkommas (').

Ich hatte eigentlich nur die Beschreiber und die Variablen aus dem
Shell-Script mit Hochkommas versehen (und leider halt auch die
Sortierkriterien). Die Spalten etc. habe ich "nackt" notiert. Falsch?

> Außerdem gibt es in Deiner Ausgabe keine Spalte "Person", sondern nur
> eine Spalte "P" (per AS festgelegt). Korrigiere das mal, und dann
> schauen wir weiter.

Vor meinem Kontakt mit UNION war ich es gewohnt, sowohl nach dem
Spaltennamen als auch nach dem Alias sortieren zu können.

Das Problem lag aber in erster Linie an den Parametern zum "ORDER BY".
Jetzt funktioniert es, in meiner Antwort an Axel ist das ganze
Konstrukt in funktionierender Form angehängt.

Auch Dir nen herzlichen Dank!

Gruß
Volker

[Volker Englisch]

Am 14.03.13 schrieb Axel Schwenke:

> Volker Englisch <23C5...@rsli.de> wrote:
>> Mein Versuch, zwei Tabellen in einer Ausgabe
>> zusammenzuführen, sieht nach mehrmaligem Lesen der Doku so aus:
>>
>> mysql -u "$DBUSER" -p"$DBPW" -t -e"
>> (SELECT DATE_FORMAT(Datum, '%d.%m.%Y') as Tag,
>> Person COLLATE latin1_german2_ci as 'P',
>> DATE_FORMAT(Von, '%H:%i') as Von,
>> Text as 'Text/Bis'
>> FROM Termine
>> WHERE Datum like '$RANGE%')
>> UNION
>> (SELECT DATE_FORMAT(Datum, '%d.%m.%Y'),
>> Person COLLATE latin1_german2_ci,
>> DATE_FORMAT(Von, '%H:%i'),
>> DATE_FORMAT(Bis, '%H:%i')
>> FROM Arbeitszeit
>> WHERE Datum like '$RANGE%' AND Person='S')
>> ORDER BY 'Tag','Person'" "$DB"
>
>> Heraus kommt das:
> ...
>> Von dem "ORDER BY" ist irgendwie nicht sehr viel zu erkennen.
>> Vielleicht sieht ja jemand von Euch auf Anhieb, was ich falsch mache?
>
> Ja. Du sortierst nach den konstanten Strings 'Tag' und 'Person'.

Ist mir inzwischen auch aufgefallen, aber warum meckert MySQL da nicht?
Ist doch eigentlich unlogisch, nach einer Konstanten zu sortieren, oder
gibts dafür tatsächlich eine sinnvolle Verwendung?

> Und selbst wenn das Quoting korrekt wäre,

Was am Quoting ist denn verkehrt? Außer den Hochkommas vor und nach dem
Sortierwert?

> wäre es die Semantik nicht.
> ORDER BY für eine UNION kann nur Spalten/Aliase aus dem ersten SELECT
> oder (hier IMHO besser) Spalten-Nummern (... ORDER BY 1, 2)
>
> Handbuch lesen! http://dev.mysql.com/doc/refman/5.6/en/union.html

Hab ich gemacht, mehrfach sogar, aber offensichtlich nicht ganz
verstanden. Bezüglich der Spaltennummern stand da IIRC, daß man selbige
möglichst nicht verwenden soll, da obsolet.

Anyway, danke für den Wink mit dem Zaunpfahl. Jetzt siehts so aus und
funktioniert prächtig:

mysql -u "$DBUSER" -p"$DBPW" -t -e"
(SELECT DATE_FORMAT(Datum, '%d.%m.%Y') as Tag,
Person COLLATE latin1_german2_ci as 'P',
DATE_FORMAT(Von, '%H:%i') as Von,
Text as 'Text/Bis'
FROM Termine
WHERE Datum like '$RANGE%')
UNION
(SELECT DATE_FORMAT(Datum, '%d.%m.%Y'),
Person COLLATE latin1_german2_ci,
DATE_FORMAT(Von, '%H:%i'),
DATE_FORMAT(Bis, '%H:%i')
FROM Arbeitszeit
WHERE Datum like '$RANGE%' AND Person='S')

ORDER BY 1,2" "$DB"

Gruß
Volker

[Gustaf Mossakowski]

Bernd Nawothnig schrieb:

> On 2013-03-14, Claus Reibenstein wrote:

>> So weit ich wei�, m�ssen (Spalten-, Tabellen-, Alias- etc.)Namen in

>> Backticks (`) eingeschlossen werden und nicht in Hochkommas (').
>
> Da muss nicht nur nichts eingeschlossen werden, in aller Regel sollte

> man das sogar ausdr�cklich nicht machen. SQL ist nun mal case

> insensitive und wenn man das akzeptiert, braucht da auch nichts
> gequotet zu werden.

Warum sollte man Tabellennamen etc. nicht in Backticks einschlie�en?
Hast du da einen Link oder einen Suchbegriff, um dar�ber etwas zu lesen?

Was hat das mit Klein- und Gro�schreibung zu tun?

Viele Gr��e, Gustaf

[Bernd Nawothnig]

On 2013-03-14, Gustaf Mossakowski wrote:
> Warum sollte man Tabellennamen etc. nicht in Backticks einschließen?
> Hast du da einen Link oder einen Suchbegriff, um darüber etwas zu lesen?
>
> Was hat das mit Klein- und Großschreibung zu tun?

Es sollte was damit zu tun haben, wenn MySQL sich an den Standard
hielte, was ich annahm. Es hält sich aber nicht daran.

Weder die Backticks (es müssten doublequotes '"' sein) noch das Verhalten bei
gequoteten Bezeichnern (die müssten dann case sensitive interpretiert
werden) ist standardkonform.




Bernd

[Thomas 'PointedEars' Lahn]

Gustaf Mossakowski wrote:

> Bernd Nawothnig schrieb:
>> On 2013-03-14, Claus Reibenstein wrote:

>>> So weit ich weiß, müssen (Spalten-, Tabellen-, Alias- etc.)Namen in

>>> Backticks (`) eingeschlossen werden und nicht in Hochkommas (').
>>
>> Da muss nicht nur nichts eingeschlossen werden, in aller Regel sollte

>> man das sogar ausdrücklich nicht machen. SQL ist nun mal case

>> insensitive und wenn man das akzeptiert, braucht da auch nichts
>> gequotet zu werden.
>

> Warum sollte man Tabellennamen etc. nicht in Backticks einschließen?

Man sollte es tun; nur zum Testen braucht man es nicht unbedingt (da man da
die Name und Version kennt). Ich hab' es mir aber auch für den letzteren
Fall angewöhnt.

> Hast du da einen Link oder einen Suchbegriff, um darüber etwas zu lesen?

Die Empfehlung, Backticks zu verwenden, steht im MySQL-Handbuch bzw. ergibt
sich daraus.

> Was hat das mit Klein- und Großschreibung zu tun?

Nichts. MySQL-Keywords sind case-insensitive (Gross-/Kleinschreibung ist
also *egal*, ein Keyword wie „select“ ist ohne Quoting *immer* ein Keyword)
und *versionsspezifisch*; *genau* *deshalb* das Quoting mit Backticks (darin
wird nämlich ein Name *niemals* als Keyword interpretiert). mysql (z. B. in
`information_schema`.`VIEWS` [1]) und Tools wie phpMyAdmin setzen die
Backticks sinnvollerweise automagisch.

Bernd hat nachweislich keine Ahnung von relationalen Datenbanken
(Stichworte: Grund von Normalisierung, Effizienz von Kreuzabfragen) im
allgemeinen und (My)SQL (Stichworte: Datentypen, Schlüssel) im besonderen.
Dafür kann er gut stänkern und dabei entweder keine Belege oder nur
Belegimitate liefern. Am besten einfach hier ignorieren, bis er sich
hoffentlich irgendwann den nötigen Minimalclue angelesen hat.

[1] <http://forums.mysql.com/read.php?100,138520,138579#msg-138579>

--
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[Thomas 'PointedEars' Lahn]

Volker Englisch wrote:

> Am 14.03.13 schrieb Axel Schwenke:
>> Volker Englisch <23C5...@rsli.de> wrote:
>>> ORDER BY 'Tag','Person'" "$DB"
>>
>>> Heraus kommt das:
>> ...
>>> Von dem "ORDER BY" ist irgendwie nicht sehr viel zu erkennen.
>>> Vielleicht sieht ja jemand von Euch auf Anhieb, was ich falsch mache?
>>
>> Ja. Du sortierst nach den konstanten Strings 'Tag' und 'Person'.
>
> Ist mir inzwischen auch aufgefallen, aber warum meckert MySQL da nicht?
> Ist doch eigentlich unlogisch, nach einer Konstanten zu sortieren,

Nein.

> oder gibts dafür tatsächlich eine sinnvolle Verwendung?

Ja. Wenn der Parameter *kein* Name ist, dann kann er auch noch ein Ausdruck
oder eine Positionsangabe sein (siehe [1]):

SELECT
…
[ORDER BY {col_name | expr | position} [ASC | DESC], ...]
…

Ein Parser hat also hier nur die Möglichkeit, zwischen Spaltenname, Ausdruck
und Position zu unterscheiden. Spaltennamen beginnen nicht mit „'“,
Positionen sind numerische Werte. Also wird 'Tag' usw. als Ausdruck
ausgewertet, d. h. als String-Literal. Dass das eine Konstante ist, darf
den Parser nicht interessieren: es ist syntaktisch korrekt. (Allenfalls
könnte er warnen. Das könnte man für eine zukünftige MySQL-Version
vorschlagen; wäre IMHO sinnvoll, da auch Funktionen *sinnlose* statische
Rückgabewerte liefern können.)

Zum Beispiel unterstützt MySQL folgende Syntax:

SELECT …
FROM …
GROUP BY 1
ORDER BY NULL

Damit wird dem Umstand Rechnung getragen, dass GROUP BY in MySQL
normalerweise gleichzeitig nach den Gruppierungsfelder sortiert.
Mit ORDER BY NULL kann man das verhindern (ibid.).

>> Und selbst wenn das Quoting korrekt wäre,
>
> Was am Quoting ist denn verkehrt? Außer den Hochkommas vor und nach dem
> Sortierwert?

„'x'“ ist das *String-Literal* mit Wert „x“. „`x`“ ist hingegen der
(Datenbank-, Tabellen-, View- oder Spalten-)*Name* „x“, wobei „x“ dann nicht
als Schlüsselwort interpretiert wird. „`x`“ wäre also gleichbedeutend mit
„x“; hingegen wäre „select“ u. U. ein Syntaxfehler, „`select`“ aber nie.

Alle Klarheiten restlos beseitigt? ;-)

>> wäre es die Semantik nicht. ORDER BY für eine UNION kann nur
>> Spalten/Aliase aus dem ersten SELECT oder (hier IMHO besser)
>> Spalten-Nummern (... ORDER BY 1, 2)
>>
>> Handbuch lesen! http://dev.mysql.com/doc/refman/5.6/en/union.html
>
> Hab ich gemacht, mehrfach sogar, aber offensichtlich nicht ganz
> verstanden. Bezüglich der Spaltennummern stand da IIRC, daß man selbige
> möglichst nicht verwenden soll, da obsolet.

Nicht ganz:

,-[1]-<http://dev.mysql.com/doc/refman/5.6/en/select.html>
|
| Use of column positions is deprecated because the syntax has been removed
^^^^^^^^^^
| from the SQL standard.

Da steht aber auch schon seit MySQL 4.1 im Handbuch, daher würde ich das
nicht allzu ernst nehmen. Auch wenn die Möglichkeit vorgesehen ist: Ich
kenne genau niemanden, der MySQL *produktiv* im standardkonformen Modus
betreibt. Dass MySQL per default _nicht_ streng standardkonform arbytet,
ist IMHO eine der Stärken von MySQL gegenüber anderen DBMS. YMMV.

[Claus Reibenstein]

Volker Englisch schrieb:

> Ich hatte eigentlich nur die Beschreiber und die Variablen aus dem
> Shell-Script mit Hochkommas versehen (und leider halt auch die
> Sortierkriterien). Die Spalten etc. habe ich "nackt" notiert. Falsch?

Nackt geht auch, so lange die Namen keinem reservierten Wort entsprechen
oder Sonderzeichen enthalten.

Gruß
Claus

[Claus Reibenstein]

Volker Englisch schrieb:

> Am 14.03.13 schrieb Axel Schwenke:
>

>> Ja. Du sortierst nach den konstanten Strings 'Tag' und 'Person'.
>
> Ist mir inzwischen auch aufgefallen, aber warum meckert MySQL da nicht?

Weil es syntaktisch korrekt ist.

> Ist doch eigentlich unlogisch, nach einer Konstanten zu sortieren, oder
> gibts dafür tatsächlich eine sinnvolle Verwendung?

MySQL kümmert sich nicht um die Logik Deiner Sortierwünsche, sondern
macht einfach, was Du ihm sagst. Gilt für die meisten (oder für alle?)
Programme ebenfalls und für Computer sowieso.

Gruß
Claus

[Volker Englisch]

Am 14.03.13 schrieb Thomas 'PointedEars' Lahn:

> Volker Englisch wrote:
>> Am 14.03.13 schrieb Axel Schwenke:
>>> Volker Englisch <23C5...@rsli.de> wrote:
>>>
>>> Ja. Du sortierst nach den konstanten Strings 'Tag' und 'Person'.
>>
>> Ist mir inzwischen auch aufgefallen, aber warum meckert MySQL da nicht?
>> Ist doch eigentlich unlogisch, nach einer Konstanten zu sortieren,
>
> Nein.
>

>> oder gibts daf�r tats�chlich eine sinnvolle Verwendung?

>
> Ja. Wenn der Parameter *kein* Name ist, dann kann er auch noch ein Ausdruck
> oder eine Positionsangabe sein (siehe [1]):
>

> [...]

>
> Alle Klarheiten restlos beseitigt? ;-)

Absolut ;-) Herzlichen Dank f�r die ausf�hrliche Erkl�rung!

Volker