Re: UNION und ORDER BY

[Tim Landscheidt]

lrz...@rsli.inka.de (Volker Englisch) wrote:

> […]

> Irgendwie muss sich das Ganze doch kalendarisch richtig sortieren
> lassen - nur wie?

Du musst "datum" in den Unterabfragen auch abfragen, damit
sie in der Kombination verwendet werden können, also (unge-
testet):

| (SELECT person AS p,
| TO_CHAR(datum,'DD.MM') AS Tag,
| TO_CHAR(von,'HH24:MI') AS Von,
| text,
| datum
| FROM termine
| WHERE ((datum - '$datum') >= 0 AND (datum - '$datum') <= $tage)
| AND (druckkz = 1))
| UNION
| (SELECT person,
| TO_CHAR(datum,'DD.MM') AS Tag,
| (TO_CHAR(von,'HH24:MI') || '-' || TO_CHAR(bis,'HH24:MI')) AS Von,
| 'Arbeit [$PERSON]',
| datum
| FROM arbeitszeit
| WHERE ((datum - '$datum') >= 0 AND (datum - '$datum') <= $tage)
| AND (person = 'S'))
| ORDER BY datum

Tim

[Tim Landscheidt]

lrz...@rsli.inka.de (Volker Englisch) wrote:

>>> [...]

>>> Irgendwie muss sich das Ganze doch kalendarisch richtig sortieren
>>> lassen - nur wie?

>> Du musst "datum" in den Unterabfragen auch abfragen, damit
>> sie in der Kombination verwendet werden können, also (unge-
>> testet):

> Ja, klappt so, nur dass dann eine Spalte mit ausgegeben wird, die nicht
> gebraucht wird...

> Ich werde das Ganze also doch in Perl machen und dabei nur die
> gewünschten Spalten ausgeben. Ich hatte gehofft, dass das in "plain
> psql" auch irgendwie geht.

Wenn die Ergebnismenge nach einer Spalte sortiert werden
soll, muss diese auch darin enthalten sein. Du kannst aller-
dings mit PostgreSQL die sortierte Ergebnismenge als Unter-
abfrage einer weiteren Abfrage nehmen, in der Du "datum"
dann weglässt. /Aber/ in diesem Fall ist der Erhalt der Sor-
tierung nicht garantiert, und zukünftige PostgreSQL-Versio-
nen könnten sie eventuell wegoptimieren.

Tim

[Wolfgang May]

Tim Landscheidt <t...@tim-landscheidt.de> wrote:
> lrz...@rsli.inka.de (Volker Englisch) wrote:
>
>>>> [...]
>
>>>> Irgendwie muss sich das Ganze doch kalendarisch richtig sortieren
>>>> lassen - nur wie?
>
>>> Du musst "datum" in den Unterabfragen auch abfragen, damit
>>> sie in der Kombination verwendet werden können, also (unge-
>>> testet):
>
>> Ja, klappt so, nur dass dann eine Spalte mit ausgegeben wird, die nicht
>> gebraucht wird...

mach halt ein select auf die gesuchten Spalten aussenrum dazu (s.u.).

>> Ich werde das Ganze also doch in Perl machen und dabei nur die
>> gewünschten Spalten ausgeben. Ich hatte gehofft, dass das in "plain
>> psql" auch irgendwie geht.

> Wenn die Ergebnismenge nach einer Spalte sortiert werden
> soll, muss diese auch darin enthalten sein.

Enthalten sein muss sie, man muss sie aber nicht ausgeben.
Z.B in "meiner" DB (geo-zeug fuer Lehre).
select name from ((select name, population from country) union (select name, population from city)) bla order by population desc nulls last;
Geht sowohl in Oracle (<http://www.semwebtech.org/sqlfrontend/>)
als auch in postgres (hier lokal gerade ein 9.3.9).

Das muesste sich schematisch 1:1 auf die Anwendung des OP uebertragen lassen.

Wolfgang

[Volker N. Englisch]

Wolfgang May schrieb am 09.11.2015:
> Tim Landscheidt <t...@tim-landscheidt.de> wrote:
>> lrz...@rsli.inka.de (Volker Englisch) wrote:
>>
>>>>> Irgendwie muss sich das Ganze doch kalendarisch richtig sortieren
>>>>> lassen - nur wie?
>>
>>>> Du musst "datum" in den Unterabfragen auch abfragen, damit
>>>> sie in der Kombination verwendet werden können, also (unge-
>>>> testet):
>>
>>> Ja, klappt so, nur dass dann eine Spalte mit ausgegeben wird, die nicht
>>> gebraucht wird...
>
> mach halt ein select auf die gesuchten Spalten aussenrum dazu (s.u.).
>

> Enthalten sein muss sie, man muss sie aber nicht ausgeben.
> Z.B in "meiner" DB (geo-zeug fuer Lehre).
> select name from ((select name, population from country) union (select name, population from city)) bla order by population desc nulls last;

Wenn ich nichts übersehen habe, müsste es so passen. Klappt leider
nicht...:

SELECT p,tag,von,text FROM
(

(SELECT person AS p,
TO_CHAR(datum,'DD.MM') AS Tag,
TO_CHAR(von,'HH24:MI') AS Von,

text AS text

FROM termine
WHERE ((datum - '$datum') >= 0 AND (datum - '$datum') <= $tage)
AND (druckkz = 1)
)
UNION
(SELECT person,
TO_CHAR(datum,'DD.MM') AS Tag,
(TO_CHAR(von,'HH24:MI') || '-' || TO_CHAR(bis,'HH24:MI')) AS Von,

'Arbeit [$PERSON]' AS text

FROM arbeitszeit
WHERE ((datum - '$datum') >= 0 AND (datum - '$datum') <= $tage)
AND (person = 'S')
)

)

ergibt

| FEHLER: Unteranfrage in FROM muss Aliasnamen erhalten
| ZEILE 3: (
| ^
| TIP: Zum Beispiel FROM (SELECT ...) [AS] xyz.

Setze ich ans Ende jedes Unter-SELECTs ein "AS ...", passiert
folgendes:

| FEHLER: Syntaxfehler bei »AS«
| ZEILE 10: AND (druckkz = 1) AS bla)
| ^

$ psql --version
psql (PostgreSQL) 8.4.9
enthält Unterstützung für Kommandozeilenbearbeitung

V*

[Wolfgang May]

Volker N. Englisch <lrz...@rsli.inka.de> wrote:
> Wolfgang May schrieb am 09.11.2015:
>> Tim Landscheidt <t...@tim-landscheidt.de> wrote:
>>> lrz...@rsli.inka.de (Volker Englisch) wrote:
>>>
>>>>>> Irgendwie muss sich das Ganze doch kalendarisch richtig sortieren
>>>>>> lassen - nur wie?
>>>
>>>>> Du musst "datum" in den Unterabfragen auch abfragen, damit
>>>>> sie in der Kombination verwendet werden können, also (unge-
>>>>> testet):
>>>
>>>> Ja, klappt so, nur dass dann eine Spalte mit ausgegeben wird, die nicht
>>>> gebraucht wird...
>>
>> mach halt ein select auf die gesuchten Spalten aussenrum dazu (s.u.).
>>
>> Enthalten sein muss sie, man muss sie aber nicht ausgeben.
>> Z.B in "meiner" DB (geo-zeug fuer Lehre).
>> select name from ((select name, population from country) union (select name, population from city)) bla order by population desc nulls last;
>
> Wenn ich nichts übersehen habe, müsste es so passen. Klappt leider
> nicht...:

doch, muesste wenn man das "bla"-alias richtig (ganz aussen bei Dir) setzt, gehen:

> SELECT p,tag,von,text FROM
> (
> (SELECT person AS p,
> TO_CHAR(datum,'DD.MM') AS Tag,
> TO_CHAR(von,'HH24:MI') AS Von,
> text AS text
> FROM termine
> WHERE ((datum - '$datum') >= 0 AND (datum - '$datum') <= $tage)
> AND (druckkz = 1)
> )
> UNION
> (SELECT person,
> TO_CHAR(datum,'DD.MM') AS Tag,
> (TO_CHAR(von,'HH24:MI') || '-' || TO_CHAR(bis,'HH24:MI')) AS Von,
> 'Arbeit [$PERSON]' AS text
> FROM arbeitszeit
> WHERE ((datum - '$datum') >= 0 AND (datum - '$datum') <= $tage)
> AND (person = 'S')
> )
> )

bla <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

> ergibt
>
> | FEHLER: Unteranfrage in FROM muss Aliasnamen erhalten
> | ZEILE 3: (
> | ^
> | TIP: Zum Beispiel FROM (SELECT ...) [AS] xyz.
>
> Setze ich ans Ende jedes Unter-SELECTs ein "AS ...", passiert
> folgendes:
>
> | FEHLER: Syntaxfehler bei »AS«
> | ZEILE 10: AND (druckkz = 1) AS bla)

Nee, da drinnen brauchts es nicht. Es wills fuer die aeussere Klammer des
from ((..) union(..))
(die ja auch eine SQL-Anfrage ist).

Analog bei mir:

****
thedb=# select name from ((select name from city) union (select name from country));
ERROR: subquery in FROM must have an alias
LINE 1: select name from ((select name from city) union (select name...
^
HINT: For example, FROM (SELECT ...) [AS] foo.
thedb=# select name from ((select name from city) union (select name from country)) bla;
name
-------------------------------------
Itajaí
Prokopjevsk
:
****


geht.

Wolfgang

[Peter Schneider]

Am 09.11.2015 um 14:38 schrieb Volker Englisch:
> Ich möchte zwei Abfragen in PostgreSQL in eine Ausgabe zusammenführen,
> was soweit auch wie geplant klappt.
>
> Leider bekomme ich das Ergebnis nur nach Tag und Monat sortiert - also
> erst alle Tage sortiert, dann die Monate - was irgendwie auch logisch
> ist:
>
> ------------------------------ cut ----------------------------------
>
> datum=`date +"%Y-%m-%d"`
> tage=28

>
> (SELECT person AS p,
> TO_CHAR(datum,'DD.MM') AS Tag,
> TO_CHAR(von,'HH24:MI') AS Von,
> text

> FROM termine
> WHERE ((datum - '$datum') >= 0 AND (datum - '$datum') <= $tage)
> AND (druckkz = 1))
> UNION
> (SELECT person,
> TO_CHAR(datum,'DD.MM') AS Tag,
> (TO_CHAR(von,'HH24:MI') || '-' || TO_CHAR(bis,'HH24:MI')) AS Von,
> 'Arbeit [$PERSON]'

> FROM arbeitszeit
> WHERE ((datum - '$datum') >= 0 AND (datum - '$datum') <= $tage)
> AND (person = 'S'))

> ORDER BY Tag, Von
>
> ------------------------------ cut ----------------------------------
>
> Ersetze ich im ORDER BY den "Tag" durch "datum", bekomme ich folgenden
> Fehler:
>
> FEHLER: Spalte »datum« existiert nicht
> ZEILE 17: ORDER BY datum, von
> ^
>
> Ersetze ich im ORDER BY den "Tag" durch "arbeitszeit.datum,
> termine.datum" kommt dieser Fehler:
>
> FEHLER: fehlender Eintrag in FROM-Klausel für Tabelle »termine«
> ZEILE 17: ORDER BY termine.datum, arbeitszeit.datum, von
> ^

>
> Irgendwie muss sich das Ganze doch kalendarisch richtig sortieren
> lassen - nur wie?

In Oracle würde man sich auf die relative Spaltennummer beziehen, also:

...
ORDER BY 2, 3

Vielleicht geht das in PostgreSQL genauso? Hab grad keins zum Testen hier...

Gruß
Peter

--
Climb the mountain not to plant your flag, but to embrace the challenge,
enjoy the air and behold the view. Climb it so you can see the world,
not so the world can see you. -- David McCullough Jr.

[Volker N. Englisch]

Peter Schneider schrieb am 12.11.2015:
> Am 09.11.2015 um 14:38 schrieb Volker Englisch:
>> Ich möchte zwei Abfragen in PostgreSQL in eine Ausgabe zusammenführen,
>> was soweit auch wie geplant klappt.
>>
>> Leider bekomme ich das Ergebnis nur nach Tag und Monat sortiert - also
>> erst alle Tage sortiert, dann die Monate - was irgendwie auch logisch
>> ist:
>>

>> FEHLER: Spalte »datum« existiert nicht
>> ZEILE 17: ORDER BY datum, von
>> ^
>

> In Oracle würde man sich auf die relative Spaltennummer beziehen, also:
> ...
> ORDER BY 2, 3
>
> Vielleicht geht das in PostgreSQL genauso? Hab grad keins zum Testen hier...

Geht in PostgresSQL auch so. Das Problem war aber, dass die zu
sortierende Spalte in der Abfrage vorkommen muss, und wie ich die
trotzdem bei der Ausgabe unterdrückt bekomme. Hat sich inzwischen
geklärt, siehe Thread.

Dir trotzdem ein Dankeschön!

V*

[Claus Reibenstein]

Volker Englisch schrieb am 11.11.2015 um 18:23:

> WHERE ((datum - '$datum') >= 0 AND (datum - '$datum') <= $tage)

WHERE (datum - '$datum') BETWEEN 0 AND $tage

Gruß
Claus

[Jörg Burzeja]

Bei MSSQL:

BETWEEN wird von einem Index nicht berücksichtigt; >= bzw. <= sehr wohl.
Bei großen Datenmengen also schon wesentlich.

OB es bei MySQL auch so ist kann nicht nicht sagen.

[Peter J. Holzer]

On 2015-11-17 18:32, Jörg Burzeja <No_Spam...@gmx.de> wrote:
> Am 16.11.2015 um 09:08 schrieb Claus Reibenstein:
>> Volker Englisch schrieb am 11.11.2015 um 18:23:
>>
>>> WHERE ((datum - '$datum') >= 0 AND (datum - '$datum') <= $tage)
>>
>> WHERE (datum - '$datum') BETWEEN 0 AND $tage
>
>
> Bei MSSQL:
>
> BETWEEN wird von einem Index nicht berücksichtigt; >= bzw. <= sehr wohl.

Seltsame Einschränkung. "x between y and z" in "x >= y and x <= z"
umzuwandeln ist doch eine eher triviale Operation.

> OB es bei MySQL auch so ist kann nicht nicht sagen.

Volker verwendet Postgres, das verwendet bei between jedenfalls einen
Index (wenn es sinnvoll ist):

hjp=> explain analyze select * from t where i between 1000 and 1050;
QUERY PLAN
--------------------------------------------------------------------------------------------------------------
Index Scan using t_i_idx on t (cost=0.00..8.75 rows=25 width=48) (actual time=0.014..0.034 rows=25 loops=1)
Index Cond: ((i >= 1000) AND (i <= 1050))
Total runtime: 0.085 ms
(3 rows)

Bei den Querys oben sehe ich aber ein anderes Problem: Welchen Wert soll
die Datenbank bei (datum - '$datum') <= $tage im Index suchen? Der
Ausdruck muss erst arithmetisch umgeformt werden, damit das Datum allein
steht:
datum <= cast('$datum' as datum) + $tage.
Das ist bei - relativ einfach, wird bei komplexeren Ausdrücken aber
nicht-trivial bis unmöglich. Ich bezweifle, dass das viele Datenbanken
machen. Postgres jedenfalls tut es nicht:

hjp=> explain analyze select * from t where i-5 between 1000 and 1050;
QUERY PLAN
--------------------------------------------------------------------------------------------------
Seq Scan on t (cost=0.00..962.36 rows=164 width=48) (actual time=0.191..18.885 rows=26 loops=1)
Filter: (((i - 5) >= 1000) AND ((i - 5) <= 1050))
Total runtime: 18.929 ms
(3 rows)

hp

--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | h...@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel

[Claus Reibenstein]

Peter J. Holzer schrieb am 19.11.2015 um 20:24:

> Seltsame Einschränkung. "x between y and z" in "x >= y and x <= z"
> umzuwandeln ist doch eine eher triviale Operation.

Kommt darauf an, wie komplex x ist.

Gruß
Claus

[Peter J. Holzer]

Nein. Das einzige worauf man aufpassen muss, ist, x nur einmal zu
evaluieren. Aber das ist von der Komplexität von x ziemlich unabhängig.

[Claus Reibenstein]

Peter J. Holzer schrieb am 22.11.2015 um 10:54:

> On 2015-11-20 19:10, Claus Reibenstein <4spame...@kabelmail.de> wrote:
>
>> Peter J. Holzer schrieb am 19.11.2015 um 20:24:
>>
>>> Seltsame Einschränkung. "x between y and z" in "x >= y and x <= z"
>>> umzuwandeln ist doch eine eher triviale Operation.
>>
>> Kommt darauf an, wie komplex x ist.
>
> Nein. Das einzige worauf man aufpassen muss, ist, x nur einmal zu
> evaluieren. Aber das ist von der Komplexität von x ziemlich unabhängig.

Aha. Dann sage mir doch bitte mal, wie man in dem gegebenen, relativ
simplen Beispiel

WHERE ((datum - '$datum') >= 0 AND (datum - '$datum') <= $tage)

dafür sorgt, dass (datum - '$datum') nur 1x evaluiert wird.

Gruß
Claus

[Wolfgang May]

Claus Reibenstein <4spame...@kabelmail.de> wrote:
> Peter J. Holzer schrieb am 22.11.2015 um 10:54:
>
>> On 2015-11-20 19:10, Claus Reibenstein <4spame...@kabelmail.de> wrote:
>>
>>> Peter J. Holzer schrieb am 19.11.2015 um 20:24:
>>>
>>>> Seltsame Einschränkung. "x between y and z" in "x >= y and x <= z"
>>>> umzuwandeln ist doch eine eher triviale Operation.
>>>
>>> Kommt darauf an, wie komplex x ist.
>>
>> Nein. Das einzige worauf man aufpassen muss, ist, x nur einmal zu
>> evaluieren. Aber das ist von der Komplexität von x ziemlich unabhängig.
>
> Aha. Dann sage mir doch bitte mal, wie man in dem gegebenen, relativ
> simplen Beispiel
>
> WHERE ((datum - '$datum') >= 0 AND (datum - '$datum') <= $tage)
>
> dafür sorgt, dass (datum - '$datum') nur 1x evaluiert wird.

Sowas schaffen schon die meisten Programmiersprachen-Compiler automatisch.
Oft sogar bei Mehrfachverwendung desselben Terms in unterschiedlichen
Programmzeilen.

Sollte IMHO auch fuer die Auswertungskomponente der Bedingungen
(unterhab der Algebra! - also im Query Plan nicht ersichtlich) kein
Problem sein.

Wolfgang

[Peter J. Holzer]

Du denkst in der falschen Ebene. Natürlich manipuliert man nicht den
Source-Code (obwohl, wie Wolfgang schon festgestellt hat, jeder halbwegs
kompetente Compiler Common Subexpression Elimination beherrscht),
sondern den Syntax-Tree. Der kann dann z.B. zu einem DAG werden (der
Knoten (datum - '$datum') würde dann zweimal referenziert) oder man
erzeugt eine Zuweisung zu einer temporären Variablen, die man dann in
den beiden Vergleichen verwendet.

Wenn Du jetzt noch in Betracht ziehst, dass Du idealerweise den Ausdruck
eben nicht für jede Zeile auswerten willst, sondern im Index möglichst
direkt an die erste passende Stelle springen und nach der letzten
abbrechen willst, also z.B.

x between y and z

x >= y and x <= z

z >= x and x >= y
etc.

alle in

suche den ersten Wert im Index >= y
solange x <= z:
tu irgendwas
nächster Indexeintrag

umwandeln willst, dann ist das wirklich vergleichsweise einfach, und die
Einschränkung wird noch rätselhafter, wenn man bedenkt, dass die
between-Form die einzige ist, die den Range-Scan direkt abbildet. In
allen anderen Fällen muss der Compiler erkennen, dass er zwei Ausdrücke
(die wie mein Beispiel zeigt unterschiedlich formuliert und in
verschiedener Reihenfolge stehen können und auch nicht unbedingt
unmittelbare Nachbarn sein müssen) zu einem Range-Scan zusammenfassen
kann.

[Peter J. Holzer]

On 2015-11-27 17:41, Stefan Ram <r...@zedat.fu-berlin.de> wrote:
> In C kann man (ich weiß aber nicht, ob das voll portabel ist)
> eine Bereichsprüfung auf [0, $tage] (ich zeige es mit $tage = 3)
> mit nur einem Vergleich erledigen:
>
> #include <stdio.h>
>
> static inline range( unsigned int i )
> { printf( "%2d, %s\n",( int )i, i < 3 ? "in range" : "" ); }
>
> int main( void )
> { for( int i = -2; i < 5; ++ i )range( i ); }
>
> -2,
> -1,
> 0, in range
> 1, in range
> 2, in range
> 3,
> 4,
>
> In MySQL gibt es zwar auch INTEGER UNSIGNED, aber ausgerechnet
> das bei den Typen und Prüfungen sonst so laxe MySQL erlaubt dort
> solche Bitreinterpretationen nicht.

In C ist ein Cast von signed int auf unsigned int keine
Bitreinterpretation, sondern eine mathematisch definierte Operation
(modulo UINT_MAX+1), die unabhängig von der Zahlenrepräsentation auf
Bitebene ist (in der üblichen Zweierkomplement-Darstellung ist die
Repräsentation allerdings tatsächlich gleich).

MySQL verwendet ebenfalls eine definierte Operation, aber eine andere:
Bei der Zuweisung an einen Integer-Typ werden Werte die zu klein sind
auf das Minimum, solche, die zu groß sind, auf das Maximum gesetzt:

mysql> desc foo;
+-------+----------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------+----------------------+------+-----+---------+-------+
| i | int(11) | YES | | NULL | |
| u | int(10) unsigned | YES | | NULL | |
| si | smallint(6) | YES | | NULL | |
| su | smallint(5) unsigned | YES | | NULL | |
+-------+----------------------+------+-----+---------+-------+
4 rows in set (0.00 sec)

...
mysql> update foo set u=i, su=i, si=i;
Query OK, 1 row affected, 13 warnings (0.00 sec)
Rows matched: 9 Changed: 1 Warnings: 13


mysql> select * from foo order by i;
+--------+-------+--------+-------+
| i | u | si | su |
+--------+-------+--------+-------+
| -70000 | 0 | -32768 | 0 |
| -40000 | 0 | -32768 | 0 |
| -30000 | 0 | -30000 | 0 |
| -1 | 0 | -1 | 0 |
| 0 | 0 | 0 | 0 |
| 1 | 1 | 1 | 1 |
| 30000 | 30000 | 30000 | 30000 |
| 40000 | 40000 | 32767 | 40000 |
| 70000 | 70000 | 32767 | 65535 |
+--------+-------+--------+-------+
9 rows in set (0.00 sec)

Ach ja, man beachte "Warnings: 13":

mysql> show warnings ;
+---------+------+---------------------------------------------+
| Level | Code | Message |
+---------+------+---------------------------------------------+
| Warning | 1264 | Out of range value for column 'u' at row 1 |
| Warning | 1264 | Out of range value for column 'su' at row 1 |
| Warning | 1264 | Out of range value for column 'si' at row 4 |
| Warning | 1264 | Out of range value for column 'su' at row 5 |
| Warning | 1264 | Out of range value for column 'si' at row 5 |
| Warning | 1264 | Out of range value for column 'u' at row 6 |
| Warning | 1264 | Out of range value for column 'su' at row 6 |
| Warning | 1264 | Out of range value for column 'si' at row 6 |
| Warning | 1264 | Out of range value for column 'u' at row 7 |
| Warning | 1264 | Out of range value for column 'su' at row 7 |
| Warning | 1264 | Out of range value for column 'si' at row 7 |
| Warning | 1264 | Out of range value for column 'u' at row 8 |
| Warning | 1264 | Out of range value for column 'su' at row 8 |
+---------+------+---------------------------------------------+
13 rows in set (0.00 sec)