Zeilen in einer Spalte mit Datum zusammenfassen

Werbung:
Liest Du auch, was ich schreibe? Z.B. in #6? Schon mal probiert?
Hat er doch.

10.1.48-MariaDB-0+deb9u2

Und so geht's weiter:

Suche nach lag

Scrollen zu Change History:
10.2 Community
  • Added in MariaDB Community Server 10.2.2.
Das bedeutet, 10.1 kann es nicht. Und man kann ebenfalls nachschlagen, dass diese Version aus 2014 ist. Das ist schon etwas her.

Interessanter Vergleich:
Das ist die älteste Postgres Version in der Standard Doku, Postgres Version 8.4.
Diese Version kann bereits lag().
Diese Version ist sehr wahrscheinlich aus dem Jahr 2009. Das ist noch viel länger her als bei MariaDB. Ich kann nur vermuten, aber es gibt diese Funktion in Postgres wahrscheinlich noch länger, als ich auf die Schnelle in der Doku finde.

Damit ergibt sich Pi mal Daumen* folgende Rechnung - am Beispiel der Funktion lag()-:
MariaDB Hoster Rückstand: 8 Jahre
MadiaDB Funktionsrückstand: 7 Jahre (zu Postgres)

Strich drunter:
15 Jahre Rückstand

Ich hoffe, Du machst das nicht freiwillig.

Jetzt kann man noch das Gedankenspiel machen und sich fragen, wieviel Jahre es dauern wird, bis man gerade veröffentlichte Funktionen von Postgres auch in MariaDB hat. Relevant ist natürlich nur all das, was kleiner Renteneintrittsalter liegt.

* Die Rechnung ist sehr grob, aber auch konservativ. Auf die 3 Nachkommastelle für Einführung von Lag bei MariaDB hab ich nicht geachtet, sicher später als 10.2(.0). In Wirklichkeit ist es also eher schlimmer.
 
Zuletzt bearbeitet:
Das ist die älteste Postgres Version in der Standard Doku, ältere Doku gibt es auch sicher irgendwo. Diese Version ist sehr wahrscheinlich aus dem Jahr 2009. Das ist noch viel länger her. Ich kann nur vermuten, aber es gibt sie wahrscheinlich noch länger, als ich auf die Schnelle in der Doku finde.
WINDOW-Functions wurden 2009 mit 8.4 in PostgreSQL eingeführt.
 
Workaround gut und schön, aber es muss ja ein Grund geben wieso CTE oder die Window Funktionen nicht gehen
Ja, der sollte jetzt klar sein. Du verwendest ein veraltetes, funktionsarmes Datenbanksystem.
Den Grund dafür kennst nur Du.

Ich will nicht hämisch wirken, aber es ist fast immer so, dass man all die fehlenden Funktionen von mySQL oder Maria über workarounds lösen muss.
 
MariaDB Hoster Rückstand: 8 Jahre
MadiaDB Funktionsrückstand: 7 Jahre (zu Postgres)
PG hat nur eine Engine - Rückstad 25 Jahre !


So etwas banales wie ISNULL gibts nicht bei PG und ist auch SQL92. PG hat nur eine ACID Engine, ......Und ich denke das PG Kommentare hier off topic. Dafür gibts ja eine eigene Kategorie :-)
 
guten morgen,
danke für die vielen Hinweise, ich versuche das mal einzuordnen :-)
@akretschmer : Ich hatte dir zugehört :-D Bisher waren deine Beiträge immer hilfreich, keine Angst, ich ignoriere deine Beiträge nicht, aber die Version hatte ich tatsächlich schon mal gepostet 🙃
@dabadepdu : tatsächlich habe ich keinen Einfluss auf die Datenbank und deren Version. Die ist extern gehostet, habe meinen Chef geben dort nachzufragen, wir warten seit letzter Woche auf eine Antwort... das nervt...


ich werde wohl doch nen workaround machen müssen, danke für die hilfreichen Links und Tipp. Ich halte euch auf dem Laufenden.
 
Hallo,

um dir mal eine Idee zu geben:

SELECT min(datum) AS von ,max(datum) AS bis ,ort FROM ( SELECT @rnr:=@rnr+1 as rnr,datum,ort from my_tab CROSS JOIN ( SELECT @rnr:=-1) AS INIT ) as tab GROUP BY rnr >> 1 ;



Beispiel


MariaDB [bernd]> SELECT * from my_tab; +----+------------+---------+ | id | datum | ort | +----+------------+---------+ | 1 | 2022-08-01 | Dresden | | 2 | 2022-08-02 | Dresden | | 3 | 2022-08-03 | Leipzig | | 4 | 2022-08-04 | Leipzig | | 5 | 2022-08-05 | Dresden | +----+------------+---------+ [B]5 rows in set (0.000 sec)[/B] MariaDB [bernd]> SELECT min(datum) AS von ,max(datum) AS bis ,ort FROM ( -> SELECT @rnr:=@rnr+1 as rnr,datum,ort -> from my_tab -> CROSS JOIN ( SELECT @rnr:=-1) AS INIT -> ) as tab -> GROUP BY rnr >> 1 ; +------------+------------+---------+ | von | bis | ort | +------------+------------+---------+ | 2022-08-01 | 2022-08-02 | Dresden | | 2022-08-03 | 2022-08-04 | Leipzig | | 2022-08-05 | 2022-08-05 | Dresden | +------------+------------+---------+ [B]3 rows in set (0.001 sec)[/B] MariaDB [bernd]>


Gruß

Bernd
 
hm, so richtig komme nicht nicht hin, meine Ausgabe ist:
Code:
SELECT min(datum) AS von, max(datum) AS bis, id_einsatzort
FROM    (
        SELECT @rnr:=@rnr+1 as rnr, datum, id_einsatzort
        FROM tb_dienstreisezeiten
        CROSS JOIN (SELECT @rnr:=-1) AS INIT
        where id_abrechnung = '12156-2022-7' and einsatzort is not null
        ) as tab
GROUP BY rnr >> 1, id_einsatzort

1661768298797.png

was ich wahrscheinlich vergessen habe zu erwähnen und das Query fehlerhaft macht, ist, dass auch mal ein Tag NULL sein kann beim Einsatzort, wie hier, der 3.7., ein Sonntag, gibt es keinen Ort.

Da dachte ich mir, ich sage die id_einsatzort darf nicht leer sein und einsatzort nicht null, da Werte bei id_einsatzort wenn keine vorhanden sind = '' und bei keinem Einsatzort = NULL

Mein neues Statemant:
Code:
SELECT min(datum) AS von, max(datum) AS bis, id_einsatzort
FROM    (
        SELECT @rnr:=@rnr+1 as rnr, datum, id_einsatzort, einsatzort
        FROM tb_dienstreisezeiten
        CROSS JOIN (SELECT @rnr:=-1) AS INIT
        where id_abrechnung = '12156-2022-7' and einsatzort is not null and id_einsatzort <> ''
        ) as tab
where einsatzort is not null and id_einsatzort <> ''
GROUP BY rnr >> 1

aber gleiches bild.

1661768614089.png
 
Werbung:
kurzes update, ich habe jetzt folgendes SQL erarbeitet, muss noch paar testen ob das alle Möglichkeiten abdeckt:

Code:
select min(t1.datum) as von, max(t2.datum) as bis, t1.einsatzort
from `tb_dienstreisezeiten` t1
left join
        (
        select datum, einsatzort
        from  `tb_dienstreisezeiten`
        where id_abrechnung = '12156-2022-7' and einsatzort is not null
        ) t2 on DATE_ADD(t2.datum, INTERVAL 1 DAY) >= t1.datum and t1.einsatzort = t2.einsatzort
where t1.id_abrechnung = '12156-2022-7' and t2.datum is not null
group by t1.einsatzort

klappt leider nicht wie geplant, da er bei wechsel auf den ersten einsatzort, dann den ersten datensatz durchägig annimmt, schade..
 
Zuletzt bearbeitet:
Zurück
Oben