I am working on a codebase which has the following type of pattern for generating surrogate key for tables.
create or replace
TRIGGER TEST_TRIG
BEFORE INSERT OR
This particular pattern is actually quite dangerous as it allows someone to manually input a new ID that might clash with an already extant surrogate key or one that your sequence might generate in the future.
Your trigger should really look like this to ensure that for every new record gets a unique key. If you're using 11.2 or higher there's no need for the select ... into ...
CREATE OR REPLACE TRIGGER TEST_TRIG
BEFORE INSERT ON my_table
FOR EACH ROW
BEGIN
:new.column1 := my_table_seq.NEXTVAL;
END;
The benefit of this approach is that it's always done. Whatever value anyone puts in for this column gets overwritten to something that will work and which uses the correct sequence; if someone forgets to add it in the statement will still work.
It makes it impossible to break your surrogate key.
With what you suggest, imagine that someone places a 1 instead; you get a primary key violation. If someone forgets then there's more errors. You'll never guarantee that every update to your table will be through a single point of entry so the trigger guarantees that the PK is populated correctly.
It's worth noting that from 12c you can use an identity column, which makes explicit the link between table and auto-increment; there's no need for a trigger or a sequence. The syntax for the table creation DDL would be:
create table ( generated as identity );