voordeel van het gebruik van een trigger om surrogaatsleutel te vullen in oracle plsql

Dit specifieke patroon is eigenlijk best gevaarlijk omdat het iemand in staat stelt handmatig een nieuwe ID in te voeren die kan botsen met een reeds bestaande surrogaatsleutel of een die uw reeks in de toekomst zou kunnen genereren.

Je trigger zou er echt zo uit moeten zien om ervoor te zorgen dat voor elk nieuw record een unieke sleutel krijgt. Als je 11.2 of hoger gebruikt, is het niet nodig om select ... into ...

CREATE OR REPLACE TRIGGER TEST_TRIG
BEFORE INSERT ON my_table
FOR EACH ROW
BEGIN
   :new.column1 := my_table_seq.NEXTVAL;
END;

Het voordeel van deze aanpak is dat het altijd . is gedaan. Welke waarde iemand ook voor deze kolom invoert, wordt overschreven naar iets dat zal werken en dat de juiste volgorde gebruikt; als iemand vergeet het in de verklaring toe te voegen, werkt het nog steeds.

Het maakt het onmogelijk om je surrogaatsleutel te breken.

Stel je bij wat je voorstelt voor dat iemand in plaats daarvan een 1 plaatst; je krijgt een schending van de primaire sleutel. Als iemand het vergeet, zijn er meer fouten. U kunt nooit garanderen dat elke update van uw tabel via één enkel toegangspunt verloopt, dus de trigger garandeert dat de PK correct wordt ingevuld.

Het is vermeldenswaard dat u vanaf 12c een identiteit kunt gebruiken kolom , die de link tussen tabel en auto-increment expliciet maakt; er is geen trigger of een reeks nodig. De syntaxis voor de DDL voor het maken van tabellen zou zijn:

create table <table_name> ( <column_name> generated as identity );