Med select max(id) + 1 tilgang, vil to sessioner, der indsættes samtidigt, se det samme aktuelle max ID fra tabellen, og begge indsætter den samme nye ID-værdi. Den eneste måde at bruge dette sikkert på er at låse bordet, før transaktionen påbegyndes, hvilket er smertefuldt og serialiserer transaktionerne. (Og som Stijn påpeger, kan værdier genbruges, hvis den højeste post slettes). Dybest set, brug aldrig denne tilgang. (Der kan meget indimellem være en tvingende grund til at gøre det, men jeg er ikke sikker på, at jeg nogensinde har set en).
Sekvensen garanterer, at de to sessioner får forskellige værdier, og der kræves ingen serialisering. Det vil yde bedre og være sikrere, nemmere at kode og nemmere at vedligeholde.
Den eneste måde du kan få duplikerede fejl ved at bruge sekvensen er, hvis der allerede findes poster i tabellen med ID'er over sekvensværdien, eller hvis noget stadig indsætter poster uden at bruge sekvensen. Så hvis du havde en eksisterende tabel med manuelt indtastede id'er, f.eks. 1 til 10, og du oprettede en sekvens med en standard startværdi på 1, ville den første indsættelse, der bruger sekvensen, forsøge at indsætte et ID på 1 - som allerede eksisterer . Efter at have prøvet det 10 gange ville sekvensen give dig 11, hvilket ville fungere. Hvis du derefter brugte max-ID-tilgangen til at lave den næste indsættelse, ville du bruge 12, men sekvensen ville stadig være på 11 og ville også give dig 12, næste gang du ringede til nextval .
Sekvensen og tabellen er ikke relaterede. Sekvensen opdateres ikke automatisk, hvis en manuelt genereret ID-værdi indsættes i tabellen, så de to tilgange blandes ikke. (Blandt andet kan den samme sekvens bruges til at generere ID'er for flere tabeller, som nævnt i dokumenterne).
Hvis du skifter fra en manuel tilgang til en sekvenstilgang, skal du sikre dig, at sekvensen er oprettet med en start-med-værdi, der er højere end alle eksisterende id'er i tabellen, og at alt, der udfører en indsættelse, bruger sekvensen kun i fremtiden.