SQL vælger kun rækker med maks. værdi på en kolonne

Ved første øjekast...

Alt du behøver er en GROUP BY klausul med MAX aggregeret funktion:

SELECT id, MAX(rev)
FROM YourTable
GROUP BY id

Det er aldrig så enkelt, er det?

Jeg har lige bemærket, at du har brug for content kolonne også.

Dette er et meget almindeligt spørgsmål i SQL:find hele data for rækken med en vis maks. værdi i en kolonne pr. gruppe-id. Det har jeg hørt meget i løbet af min karriere. Faktisk var det et af spørgsmålene, jeg besvarede i mit nuværende jobs tekniske samtale.

Det er faktisk så almindeligt, at Stack Overflow-fællesskabet har oprettet et enkelt tag bare for at håndtere sådanne spørgsmål:største-n-pr-gruppe .

Grundlæggende har du to tilgange til at løse det problem:

Tilslutning med simpel group-identifier, max-value-in-group Underforespørgsel

I denne tilgang finder du først group-identifier, max-value-in-group (allerede løst ovenfor) i en underforespørgsel. Derefter slutter du din tabel til underforespørgslen med lighed på begge group-identifier og max-value-in-group :

SELECT a.id, a.rev, a.contents
FROM YourTable a
INNER JOIN (
    SELECT id, MAX(rev) rev
    FROM YourTable
    GROUP BY id
) b ON a.id = b.id AND a.rev = b.rev

Venstre joining with self, tweaking join-betingelser og filtre

I denne tilgang forlod du slutte sig til bordet med sig selv. Ligestilling går i group-identifier . Derefter 2 smarte træk:

1. Den anden sammenføjningsbetingelse har venstre sideværdi mindre end højre værdi
2. Når du udfører trin 1, vil den eller de rækker, der faktisk har den maksimale værdi, have NULL i højre side (det er en LEFT JOIN , Husk?). Derefter filtrerer vi det samlede resultat og viser kun de rækker, hvor højre side er NULL .

Så du ender med:

SELECT a.*
FROM YourTable a
LEFT OUTER JOIN YourTable b
    ON a.id = b.id AND a.rev < b.rev
WHERE b.id IS NULL;

Konklusion

Begge tilgange giver nøjagtig samme resultat.

Hvis du har to rækker med max-value-in-group for group-identifier , vil begge rækker være i resultatet i begge tilgange.

Begge tilgange er SQL ANSI-kompatible, og vil derfor fungere med dit foretrukne RDBMS, uanset dets "smag".

Begge tilgange er også præstationsvenlige, men din kilometertal kan variere (RDBMS, DB-struktur, indekser osv.). Så når du vælger den ene tilgang frem for den anden, benchmark . Og sørg for at vælge den, der giver mest mening for dig.