SQL: Neueste Daten einer bestimmten Serien-Nr. ermitteln

[Matze]

Hallo zusammen,

ich habe eine Tabelle in der Art:

Code:

Datum/Zeit         Serien-Nr.    Wert1   Wert2   ...
12.01.15, 14:43   12345        a        b
12.01.15, 14:43   98765        a        b
12.01.15, 14:44   12345        c        d
12.01.15, 14:47   12345        e        f
12.01.15, 14:49   98765        c        d
...

Nun möchte ich für jede Serien-Nr. je den neuesten Datensatz.
In dem Fall 2 Datensätze:

Code:

12.01.15, 14:47   12345        e        f
12.01.15, 14:49   98765        c        d

Ich habe es über "GROUP BY Serien_Nr ORDER BY Datum DESC" versucht, aber das gibt mir seltsame Daten zurück. ;)

Wie geht's richtig?

Grüße
Matze

[Dejan Vu]

EDIT:

SQL-Code:

select y.* from Tabelle y
 join (select SerienNummer
            , max(Datum) as MaxDatum 
         from Tabelle group by SerienNummer
      ) x
   on x.Seriennummer = y.Seriennummer
  and x.MaxDatum = y.Datum

Hier stand vorher Murks, weil ich die Frage falsch gelesen haben bzw. nur zur Hälfte.

[DeddyH]

Ich würde es so versuchen:

SQL-Code:

SELECT
  *
FROM
  Tabelle X
WHERE 
  Datum = (
    SELECT
      MAX(Datum)
    FROM
      Tabelle
    WHERE
      Seriennummer = X.Seriennummer)

oder so:

SQL-Code:

SELECT
  *
FROM
  Tabelle X
GROUP BY
  Seriennummer
HAVING
  Datum = (
    SELECT
      MAX(Datum)
    FROM
      Tabelle
    WHERE
      Seriennummer = X.Seriennummer)

[Dejan Vu]

Die zweite Query läuft? Müssen nicht alle Felder entweder in der "Group by" Klausel oder als Aggregat auftauchen :gruebel:

[p80286]

Du hast Recht

SQL-Code:

select *

ist eigentlich immer der Todesstoß für Aggregate etc.
Nemen wir den * als Platzhalter für feld1..feldn .

Gruß
K-H

[Matze]

Vielen Dank für die zahlreichen Vorschläge! :thumb:

Wo ich das hier sehe, kommt mir, dass ich fast das gleiche hier schonmal gefragt habe. :wall:
Bei Sub-Selects tu ich mich irgendwie echt schwer von der Vorstellung, was da genau passiert, weil im Prinzip 2 Queries programmiert werden, aber die innere mehrfach mit verschiedenen Parametern ausgeführt wird.

Zitat:

Zitat von DeddyH (Beitrag 1287095)

Ich würde es so versuchen:

SQL-Code:

SELECT
  *
FROM
  Tabelle X
WHERE 
  Datum = (
    SELECT
      MAX(Datum)
    FROM
      Tabelle
    WHERE
      Seriennummer = X.Seriennummer)

Grüße
Matze

[mkinzler]

In diesem Fall nicht, es wird ein Datum ermittelt, mit welchem dann die äussere Abfrage durchgeführt wird.

[Matze]

Zitat:

Zitat von mkinzler (Beitrag 1287136)

In diesem Fall nicht, es wird ein Datum ermittelt, mit welchem dann die äussere Abfrage durchgeführt wird.

Aber "MAX(Datum)" ist ja je nach Seriennummer ein anderes. :gruebel:

[Dejan Vu]

DeddyH's Abfrage funktioniert, hätte ich nicht gedacht.
Meine auch, nach einem kleinen Edit (nur die Tabelle anzeigen, nicht das verjointe Zeugs)

Allerdings haben beide den Nachteil, das doppelte Zeilen angezeigt werden, wenn es zu einer SN für das aktuellste Datum zwei Einträge gibt. Da ist dann eine windowing-Funktion besser.

[Sir Rufo]

So ist das Verfahren definitiv nicht wirklich stabil. Je nach Auflösung des Datum-Felds und Frequenz der Seriennummer-Vergabe kommt man an den Punkt, wo es Überschneidungen gibt. Hier sollte das Design auf jeden Fall überarbeitet werden.

Eine Möglichkeit wäre eine zusätzliche AutoIncrement-Spalte - ohne das System und seine Funktionsweise aber genau zu kennen, kann man hier keine vernünftige Aussage treffen, ausser es sollte etwas anders werden :)

[p80286]

Nun, die Auflösung des Datum-Feldes sollte wohl 1d betragen. Für Suchen nach dem "neuesten" Eintrag ist DateTime mit mindestens 1s Auflösung besser geeignet. Wobei der "neueste" Eintrag wohl nicht physisch gemeint ist, da ja durchaus auch Datensätze nachgetragen werden können. Dann muß nicht nur das Datum sondern auch die Uhrzeit erfasst werden.

Gruß
K-H

[Dejan Vu]

Auch da kann es zu Doppelungen kommen, so unglaublich das klingen mag, es reicht ja schon eine blöde Logik, den Zeitstempel in der Applikation 1x zu setzen aber doppelt zu perstieren. Dann steht da zwar 2x das gleiche drin (dagegen hilf ein DISTINCT), aber so richtig richtig ist das nicht.

Ich habe mir mal angewöhnt, das so eine Tabelle ein separates Flag 'IsCurrent' hat, welches entweder 1 oder 0 ist. Ein insert/delete ist dann eben etwas aufwändiger (IsCurrent muss ja mitgepflegt werden)

[Matze]

Zitat:

Zitat von Sir Rufo (Beitrag 1287164)

Eine Möglichkeit wäre eine zusätzliche AutoIncrement-Spalte - ohne das System und seine Funktionsweise aber genau zu kennen, kann man hier keine vernünftige Aussage treffen, ausser es sollte etwas anders werden :)

Ohne die Diskussion weiter verfolgt zu haben habe ich genau die Variante mit der AutoIncrement-Spalte genutzt. Das kam mir aber auch erst bei der Programmierung.
Jetzt dürfte die Abfrage sogar minimal schneller sein aufgrund des Primary Keys.

Das reicht mir auch voll und ganz aus. Danke nochmals.

[Hansa]

Bezüglich der Zeit, also dem Ausschalten irgendwelcher Zeitauflösungen bzw. Hardware-Uhrzeit etc. : Du wirst ja wohl eine ID anlegen und die ist unabhängig von allem, ausser von der momentanen Uhrzeit. Wenn jetzt da eine ID per Trigger o.ä. erzeugt wird, dann ist das so nach dem Motto : "wer zuerst kommt mahlt zuerst". Und zwar nur nach Sonnenstand. Schlägt ein Before Insert Trigger um 10:00 am 1.1.2015 (Windows/Rechnerzeit) zu und erzeugt die ID 123, es ist aber jetzt der 21.1.2015 4:05 und ein anderer Trigger schlägt wieder zu, dann hat der die ID 124 geliefert, obwohl der Rechner aus Versehen auf 1.1.1899 steht. Also : ID fortlaufend vergeben und das order by daran ausrichten.

[Matze]

Zitat:

Zitat von Hansa (Beitrag 1287220)

Also : ID fortlaufend vergeben und das order by daran ausrichten.

Die fortlaufende ID hat bei mir generell jede Tabelle, egal was ich damit mache. :thumb:
Ich habe nicht nur ORDER BY sondern auch WHERE angepasst: "WHERE x.Id = y.Id"

Grüße
Matze