Jedną z opcji byłoby użycie instead of cyngiel. Jednak to rozwiązanie wymaga zmiany nazw tabel i tworzenia widoków o nazwach, które miały. W ten sposób nie wpłyniesz na logikę aplikacji, jednak może to wpłynąć na ogólną wydajność, dlatego należy ją odpowiednio przetestować.
Niemniej jednak używanie wyzwalaczy do zmiany niewłaściwej logiki aplikacji nie jest dobrym pomysłem. Rozumiem, że czasami musimy znaleźć obejścia istniejących problemów, ale to nie rozwiązuje problemu.
W każdym razie poniżej prosty przykład, który możesz zastosować do swojej logiki
SQL> create table t ( c1 number primary key , c2 varchar2(1) ) ;
Table created.
SQL> alter table t rename to tbl_t ;
Table altered.
SQL> create view t as ( select c1 , c2 from tbl_t ) ;
View created.
Teraz tworzymy instead of wyzwalacz
SQL> create or replace trigger tr_v_t
2 instead of insert
3 on t
4 for each row
5 declare
6 pk_violation_exception exception;
7 pragma exception_init(pk_violation_exception, -00001);
8 begin
9 insert into tbl_t (c1,c2)
10 values ( :new.c1,:new.c2 );
11 exception
12 when pk_violation_exception then
13 dbms_output.put_line('ora-00001 (pk_violation_exception) captured');
14 update tbl_t
15 set c2 = :new.c2
16 where c1 = :new.c1 ;
17* end;
SQL> /
Trigger created.
Z tym wyzwalaczem każda próba naruszenia ograniczenia umożliwi aktualizację wartości w tabeli końcowej.
SQL> select * from t ;
no rows selected
SQL> insert into t values ( 1 , 'A' ) ;
1 row created.
SQL> commit ;
Commit complete.
SQL> insert into t values ( 2, 'B' ) ;
1 row created.
SQL> commit ;
Commit complete.
SQL> insert into t values ( 2, 'C' ) ;
ORA-00001 (pk_violation_exception) captured
1 row created.
SQL> select * from tbl_t ;
C1 C
---------- -
1 A
2 C
