Umgang mit Triggern - To Trigger or not to Trigger

Ein interessanter Artikel von Jürgen Sieben im RedStack-Magazin 05-2022 S.24ff

Fazit:

• Vermeidung von Triggern durch SQL
• Identity-Column
  GENERATED [ ALWAYS | BY DEFAULT [ ON NULL ] ] AS IDENTITY [ ( identity_options ) ]

  Für Dimensionen gern genommen:
  

  GENERATED BY DEFAULT ON NULL AS IDENTITY
  
  erzeugt eindeutige ID, erlaubt aber feste Singleton (-1 für nicht definiert) vorzugeben.

oder
• default Klausel
  CREATE TABLE tst (
  

  --> Es können Sequence-Werte genutzt werden.

       d_id NUMBER DEFAULT detail_seq.NEXTVAL,
       m_id NUMBER DEFAULT master_seq.CURRVAL,
  

  --> Es können Contexte genutzt werden.

       ax_usr varchar2(32 char) DEFAULT SYS_CONTEXT ('APEX$SESSION', 'APP_USER'),
       db_usr varchar2(32 char) DEFAULT SYS_CONTEXT ('USERENV', 'SESSION_USER')
     );

oder wenn sich ein Trigger nicht vermeiden läßt, dann
• Compound Trigger
  create or replace trigger trg_test_table_comp
  for delete or insert or update on test_table
  compound trigger
  
  before statement -- STUB
  is
  begin
    null;
  end before statement;
  
  before each row
  is
  begin
    :new.object_name := initcap(:new.object_name);
    :new.change_user := user;
  end before each row;
  
  after each row -- STUB
  is
  begin
    null;
  end after each row;
  
  after statement -- STUB
  is
  begin
    null;
  end after statement;
  end;
  /

Quelle: https://backoffice.doag.org/formes/pubfiles/14573018/docs/Publikationen/Red-Stack-Magazin-inkl-Business-News/2022/05-2022/05_2022-Red_Stack_Magazin_Web.pdf