vantaggio dell'utilizzo di un trigger per popolare la chiave surrogata in Oracle plsql

Questo modello particolare è in realtà piuttosto pericoloso in quanto consente a qualcuno di inserire manualmente un nuovo ID che potrebbe entrare in conflitto con una chiave surrogata già esistente o una che la tua sequenza potrebbe generare in futuro.

Il tuo trigger dovrebbe davvero assomigliare a questo per garantire che per ogni nuovo record ottenga una chiave univoca. Se stai utilizzando 11.2 o versioni successive non è necessario il select ... into ...

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

Il vantaggio di questo approccio è che è sempre fatto. Qualunque sia il valore che qualcuno inserisce per questa colonna viene sovrascritto in qualcosa che funzionerà e che utilizza la sequenza corretta; se qualcuno dimentica di aggiungerlo nella dichiarazione funzionerà ancora.

Rende impossibile rompere la tua chiave surrogata.

Con quello che suggerisci, immagina che qualcuno metta invece un 1; si ottiene una violazione della chiave primaria. Se qualcuno dimentica, ci sono più errori. Non garantirai mai che ogni aggiornamento della tua tabella avvenga attraverso un singolo punto di ingresso, quindi il trigger garantisce che il PK sia popolato correttamente.

Vale la pena notare che da 12c puoi utilizzare un'identità colonna , che rende esplicito il collegamento tra tabella e autoincremento; non c'è bisogno di un trigger o di una sequenza. La sintassi per il DDL di creazione della tabella sarebbe:

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