Oracle-триггеры для создания строки истории при обновлении

к сожалению, нет способа избежать ссылки на все имена столбцов (: OLD.это,: старый.это и т. д.) в триггерах. Однако, что вы можете сделать, это написать программу создать код триггера из определения таблицы (в USER_TAB_COLS). Затем, когда таблица изменяется, вы можете сгенерировать и скомпилировать новую копию триггеров.

посмотреть этот AskTom нити как это сделать.

в случае, если у кого-то есть тот же узкоспециализированный случай, который мы делаем (Linq access делает историю одной таблицы намного чище/проще, это то, что я сделал, чтобы упростить то, что у нас есть, приветствуем любые улучшения....это всего лишь скрипт, который будет запускаться при каждом изменении базы данных, восстанавливая триггеры аудита, основным изменением является PRAGMA AUTONOMOUS_TRANSACTION; размещение истории, генерирующей автономную транзакцию, и не заботясь о мутации (что не имеет значения для того, как мы аудит):

Declare
  cur_trig varchar(4000);
  has_ver number;
Begin
    For seq in (Select table_name, sequence_name 
              From user_tables ut, user_sequences us
              Where sequence_name = replace(table_name, '_','') || '_SEQ'
                And table_name Not Like '%$%'
                And Exists (Select 1
                            From User_Tab_Columns utc
                            Where Column_Name = 'ID' And ut.table_name = utc.table_name)
                And Exists (Select 1
                            From User_Tab_Columns utc
                            Where Column_Name = 'DATE_START' And ut.table_name = utc.table_name)
                And Exists (Select 1
                            From User_Tab_Columns utc
                            Where Column_Name = 'DATE_MODIFIED' And ut.table_name = utc.table_name))
    Loop
     --ID Insert Triggers (Autonumber for oracle!)
     cur_trig := 'CREATE OR REPLACE TRIGGER ' || seq.table_name || 'CR' || chr(10)
              || 'BEFORE INSERT ON ' || seq.table_name || chr(10)
              || 'FOR EACH ROW' || chr(10)
              || 'BEGIN' || chr(10)
              || '  SELECT ' || seq.sequence_name || '.NEXTVAL INTO :new.ID FROM DUAL;' || chr(10)
              || '  IF(:NEW.ENTITY_ID = 0) THEN' || chr(10)
              || '    SELECT sysdate, sysdate, ''31-DEC-9999'' INTO :NEW.DATE_CREATED, :NEW.DATE_START, :NEW.DATE_MODIFIED FROM DUAL;' || chr(10)
              || '  END IF;' || chr(10)
              || 'END;' || chr(10);

     Execute Immediate cur_trig;

     --History on update Triggers
     cur_trig := 'CREATE OR REPLACE TRIGGER ' || seq.table_name || '_HIST' || chr(10)
              || '  BEFORE UPDATE ON ' || seq.table_name || ' FOR EACH ROW' || chr(10)
              || 'DECLARE' || chr(10)
              || '  PRAGMA AUTONOMOUS_TRANSACTION;' || chr(10)
              || 'BEGIN' || chr(10)
              || '  INSERT INTO ' || seq.table_name || ' (' || chr(10)
              || '   DATE_MODIFIED ' || chr(10)
              || '   ,ENTITY_ID ' || chr(10);

       For col in (Select column_name
                 From user_tab_columns ut
                 Where table_name = seq.table_name
                   And column_name NOT In ('ID','DATE_MODIFIED','ENTITY_ID')
                 Order By column_name)
     Loop
       cur_trig := cur_trig || '   ,' || col.column_name || chr(10);
     End Loop;

     cur_trig := cur_trig || ') VALUES ( --ID is Automatic via another trigger' || chr(10)
                          || '   SYSDATE --DateModified Set' || chr(10)
                          || '   ,:old.ID --EntityID Set' || chr(10);

     has_ver := 0;
       For col in (Select column_name
                 From user_tab_columns ut
                 Where table_name = seq.table_name
                   And column_name NOT In ('ID','DATE_MODIFIED','ENTITY_ID')
                 Order By column_name)
     Loop
       cur_trig := cur_trig || '   ,:old.' || col.column_name || chr(10);
       If Upper(col.column_name) = 'VERSION' Then 
         has_ver := 1; 
       End If;
     End Loop;

     cur_trig := cur_trig || ');' || chr(10)
                          || ':new.DATE_MODIFIED := ''31-DEC-9999'';' || chr(10)
                          || ':new.DATE_START := SYSDATE;' || chr(10);
     If has_ver = 1 Then
       cur_trig := cur_trig || ':new.version := :old.version + 1;' || chr(10);
     End If;
     cur_trig := cur_trig || 'COMMIT;' || chr(10)
                          || 'END;' || chr(10);

     Execute Immediate cur_trig;
    End Loop;
End;
/

Если вы можете улучшить, не стесняйтесь...Я написал только несколько скриптов PL/SQL, необходимость не возникает часто...вероятно, там еще многое оставалось желать лучшего.

ответ кредит APC за то, что заставил меня посмотреть на это немного сложнее. Я не рекомендую этот макет истории, если это не остальная часть вашей модели/приложения / стека очень хорошо. Для этого приложения мы постоянно показываем смесь истории и текущей, а также фильтрации намного проще, чем комбинировать, когда дело доходит до доступа к стилю Linq-to-SQL. Спасибо за все ответы, ребята, за все хорошие предложения...и когда у меня будет больше времени, а график выпуска не будет давить на меня, я вернусь к этому вопросу, чтобы посмотреть, можно ли его улучшить.

Я понимаю, что ваши требования к приложению specifc должны иметь историю и текущие значения в одной таблице, но, возможно, это можно было бы обработать, спустившись по более обычному маршруту наличия отдельной таблицы аудита, но построив ее как псевдо-материализованное представление для представления объединенного представления для приложения.

для меня это имеет преимущество иметь простое "текущее" представление и отдельное, но полностью автоматизированное" аудиторское " представление (которое в этом случае также имеет текущее вид.)

что-то типа:

create sequence seq_contact start with 1000 increment by 1 nocache nocycle;

create table contact (
    contact_id integer,
    first_name varchar2(120 char),
    last_name varchar2(120 char),
    last_update_date date
    );

alter table contact add constraint pk_contact primary key (contact_id);

create table a$contact (
    version_id integer,
    contact_id integer,
    first_name varchar2(120 char),
    last_name varchar2(120 char),
    last_update_date date
    );

alter table a$contact add constraint pk_a$contact primary key
        (contact_id, version_id);

create or replace trigger trg_contact
before insert or delete or update on contact 
for each row
declare

    v_row contact%rowtype;
    v_audit a$contact%rowtype;

begin

    select seq_contact.nextval into v_audit.version_id from dual;

    if not deleting then

        :new.last_update_date := sysdate;

    end if;

    if inserting or updating then

        v_audit.contact_id := :new.contact_id;
        v_audit.first_name := :new.first_name;
        v_audit.last_name := :new.last_name;
        v_audit.last_update_date := :new.last_update_date;

    elsif deleting then

        v_audit.contact_id := :old.contact_id;
        v_audit.first_name := :old.first_name;
        v_audit.last_name := :old.last_name;
        v_audit.last_update_date := sysdate;

    end if;

    insert into a$contact values v_audit;

end trg_contact;
/

insert into contact (contact_id, first_name, last_name) values
    (1,'Nick','Pierpoint');

insert into contact (contact_id, first_name, last_name) values
    (2, 'John', 'Coltrane');

insert into contact (contact_id, first_name, last_name) values
    (3, 'Sonny', 'Rollins');

insert into contact (contact_id, first_name, last_name) values
    (4, 'Kenny', 'Wheeler');

update contact set last_name = 'Cage' where contact_id = 1;

delete from contact where contact_id = 1;

update contact set first_name = 'Zowie' where contact_id in  (2,3);

select * from a$contact order by contact_id, version_id;

VERSION_ID  CONTACT_ID  FIRST_NAME  LAST_NAME  LAST_UPDATE_DATE
1000        1           Nick        Pierpoint  11/02/2010 14:53:49
1004        1           Nick        Cage       11/02/2010 14:54:00
1005        1           Nick        Cage       11/02/2010 14:54:06
1001        2           John        Coltrane   11/02/2010 14:53:50
1006        2           Zowie       Coltrane   11/02/2010 14:54:42
1002        3           Sonny       Rollins    11/02/2010 14:53:51
1007        3           Zowie       Rollins    11/02/2010 14:54:42
1003        4           Kenny       Wheeler    11/02/2010 14:53:53

Если вы хотите разработать общее решение, вы можете взглянуть на пакет DBMS_SQL. С его помощью вы можете разработать пакет/процедуру, которая принимает имя таблицы в качестве входных данных и строит обновления на основе этого, изучая структуру таблицы в словаре и создавая обновления на лету. Это будет нетривиальная предварительная разработка, но намного меньше обслуживания в будущем, так как если структура таблицы изменится, код почувствует это и адаптируется. Этот метод будет работать для любой стол, с которым вы захотите его использовать.

в зависимости от сложности вашей базы данных (количество таблиц, размер, глубина отношений PK/FK, другая логика в триггерах), вы можете посмотреть на Oracle Workspace Management. Вызов API для размещения таблицы в разделе Управление рабочей областью приводит к замене Oracle таблицы на обновляемое представление и другие соответствующие объекты, которые поддерживают историю всех версий строк.

Я использовал это, и хотя есть недостатки, один преимущество аудита заключается в том, что все объекты кода генерируются Oracle и их правильность обычно предполагается.

единственный раз, когда я мог бы рекомендовать, чтобы исторические записи хранились в той же таблице, что и "текущие" записи, - это когда ссылки FK на записи должны или могут потребоваться. Например, одно приложение, которое я видел, имело некоторые ссылки FK, которые будут ссылаться на запись с "момента времени", то есть, если запись была обновлена, FK все равно будет ссылаться на историческую запись - это была важная часть дизайна, и разделение записей истории на вторую таблицу сделало бы это более громоздкий.

кроме того, я бы предпочел, чтобы бизнес-требование для отслеживания всех изменений было решено с помощью отдельной таблицы "история" для каждой таблицы. Конечно, это означает больше DDL, но это значительно упрощает код приложения, и вы также выиграете от лучшей производительности и масштабируемости.