首先，我们目前有所需的行为，但是在需要对数据库进行任何更改时进行维护并非易事。我正在寻找更简单，更高效或更容易维护的东西（任何可以做任何这3个的东西都是最受欢迎的）。当我们执行更新时，会创建一个历史记录行，该行是当前行的副本，然后更新当前行的值。结果是我们有一个关于行在更新之前的历史记录。
推理：我们必须遵守一系列联邦规则，然后通过这条路线获得所有内容的完整审核历史记录，以及我们可以随时查看数据库并查看事物的外观（未来要求）。 出于类似原因，我无法更改历史记录的记录方式 ...任何解决方案都必须生成与当前触发器创建的数据相同的数据。
以下是Contact表的当前触发器的外观：
（为了简洁，剥离无用字段，字段数无关紧要）
更新前（每行）：
DECLARE
indexnb number;
BEGIN
:new.date_modified := '31-DEC-9999';
indexnb := STATE_PKG.newCONTACTRows.count + 1;
:new.date_start := sysdate;
:new.version := :old.version + 1;
state_pkg.newCONTACTRows(indexnb).ID := :old.ID;
state_pkg.newCONTACTRows(indexnb).PREFIX := :old.PREFIX;
state_pkg.newCONTACTRows(indexnb).FIRST_NAME := :old.FIRST_NAME;
state_pkg.newCONTACTRows(indexnb).MIDDLE_NAME := :old.MIDDLE_NAME;
state_pkg.newCONTACTRows(indexnb).LAST_NAME := :old.LAST_NAME;
--Audit columns after this
state_pkg.newCONTACTRows(indexnb).OWNER := :old.OWNER;
state_pkg.newCONTACTRows(indexnb).LAST_USER := :old.LAST_USER;
state_pkg.newCONTACTRows(indexnb).DATE_CREATED := :old.DATE_CREATED;
state_pkg.newCONTACTRows(indexnb).DATE_MODIFIED := sysdate;
state_pkg.newCONTACTRows(indexnb).VERSION := :old.VERSION;
state_pkg.newCONTACTRows(indexnb).ENTITY_ID := :old.id;
state_pkg.newCONTACTRows(indexnb).RECORD_STATUS := :old.RECORD_STATUS;
state_pkg.newCONTACTRows(indexnb).DATE_START := :old.DATE_START;
END;
更新前（所有行一次）：
BEGIN
state_pkg.newCONTACTRows := state_pkg.eCONTACTRows;
END;
更新后（所有行一次）：
DECLARE
BEGIN
for i in 1 .. STATE_PKG.newCONTACTRows.COUNT loop
INSERT INTO "CONTACT" (
ID,
PREFIX,
FIRST_NAME,
MIDDLE_NAME,
LAST_NAME,
OWNER,
LAST_USER,
DATE_CREATED,
DATE_MODIFIED,
VERSION,
ENTITY_ID,
RECORD_STATUS,
DATE_START)
VALUES (
CONTACT_SEQ.NEXTVAL,
state_pkg.newCONTACTRows(i).PREFIX,
state_pkg.newCONTACTRows(i).FIRST_NAME,
state_pkg.newCONTACTRows(i).MIDDLE_NAME,
state_pkg.newCONTACTRows(i).LAST_NAME,
state_pkg.newCONTACTRows(i).OWNER,
state_pkg.newCONTACTRows(i).LAST_USER,
state_pkg.newCONTACTRows(i).DATE_CREATED,
state_pkg.newCONTACTRows(i).DATE_MODIFIED,
state_pkg.newCONTACTRows(i).VERSION,
state_pkg.newCONTACTRows(i).ENTITY_ID,
state_pkg.newCONTACTRows(i).RECORD_STATUS,
state_pkg.newCONTACTRows(i).DATE_START
);
end loop;
END;
定义为的包（修剪完整版只是每个表的副本）：
PACKAGE STATE_PKG IS
TYPE CONTACTArray IS TABLE OF CONTACT%ROWTYPE INDEX BY BINARY_INTEGER;
newCONTACTRows CONTACTArray;
eCONTACTRows CONTACTArray;
END;
以下是结果历史样本：
ID First Last Ver Entity_ID Date_Start Date_Modified
1196 John Smith 5 0 12/11/2009 10:20:11 PM 12/31/9999 12:00:00 AM
1201 John Smith 0 1196 12/11/2009 09:35:20 PM 12/11/2009 10:16:49 PM
1203 John Smith 1 1196 12/11/2009 10:16:49 PM 12/11/2009 10:17:07 PM
1205 John Smith 2 1196 12/11/2009 10:17:07 PM 12/11/2009 10:17:19 PM
1207 John Smith 3 1196 12/11/2009 10:17:19 PM 12/11/2009 10:20:00 PM
1209 John Smith 4 1196 12/11/2009 10:20:00 PM 12/11/2009 10:20:11 PM
每个历史记录都有一个Entity_ID，它是当前行的ID，新记录上的Date_Start与最后一个历史记录行的Date_Modified匹配。这允许我们执行Where Entity_ID = :id Or ID = :id And :myDate < Date_Modified And :myDate >= Date_Start之类的查询。可以通过Entity_ID = :current_id获取历史记录。
是否有更好的方法，希望更具可维护性/灵活性？概念很简单，在更新行时，通过带旧值的插入将其复制到同一个表中，然后更新当前行...但实际上这样做，我还没有找到一种更简单的方法。我希望甲骨文中有一个更狡猾/更聪明的人有更好的方法。速度并不重要，我们99％读取1％像大多数Web应用程序一样写入，并且所有批量操作都是插入，而不是不会创建任何历史记录的更新。
如果有人有任何简化维护的想法，我会非常感激，谢谢！
答案 0 :(得分：4)
不幸的是，没有办法避免在触发器中引用所有列名（：OLD.this，：OLD.that等）。但是，您可以做的是从表定义（在USER_TAB_COLS中）编写一个程序来生成触发器代码。然后，无论何时更改表，您都可以生成并编译触发器的新副本。
请参阅this AskTom thread了解如何操作。
答案 1 :(得分：4)
好的，这是重写。我第一次回复时错过的是应用程序将其历史存储在主表中。现在我明白为什么@NickCraver对代码抱歉了。
首先要做的是找出这个设计的肇事者，并确保他们再也不会这样做了。像这样存储历史不会扩展，使正常（非历史）查询更复杂并破坏关系完整性。显然有些情况下这些都不重要，也许你的网站就是其中之一，但总的来说这是一个非常糟糕的实现。
执行此操作的最佳方式是Oracle 11g Total Recall。这是一个优雅的解决方案，具有完全隐形和高效的实现，并且 - 根据Oracle的其他收费标准 - 价格相当合理。
但如果Total Recall不可能而你真的必须这样做，不允许更新。对现有CONTACT记录的更改应该是插入。为了完成这项工作，您可能需要使用INSTEAD OF触发器构建视图。它仍然令人讨厌，但并不像你现在拥有的那样令人讨厌。
自Oracle 11.2.0.4起，Total Recall已被重新命名为Flashback Archive，并作为企业许可证的一部分提供（尽管我们购买了Advanced Compress选项，但除了压缩的日志表之外）。
甲骨文的这一慷慨应该使FDA成为存储历史的常规方式：它是高效的，它是表演性的，它是一个内置的Oracle，具有支持历史查询的标准语法。唉，我希望看到半熟的实现与spatchcocked触发器，破坏主键和多年来可怕的性能。因为日记本似乎是开发人员喜欢的那些干扰之一，尽管它是低级别的管道，这在很大程度上与99.99％的业务运营无关。
答案 2 :(得分：4)
如果有人拥有相同的高度专业化的案例（Linq访问使单表历史更清洁/更容易，这就是我最终做的简化我们所拥有的，欢迎任何改进......这只是一个每当数据库发生变化时将运行的脚本，重新生成审计触发器，主要变化是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样式访问时，过滤比组合简单得多。感谢所有答案的人，所有好的建议......当我有更多的时间而且没有受到发布时间表的影响时，我会重新审视这一点，看看是否可以进一步改进。
答案 3 :(得分：2)
我理解您的特定应用程序要求，以便在同一个表中包含历史记录和当前值，但也许这可以通过使用单独的审计表的更常见路径来处理，但是将其构建为伪物化视图提出申请的综合视图。
对我来说，这样做的好处是拥有一个简单的“当前”视图和一个单独但完全自动化的“审计”视图（在这种情况下也有当前视图）。
类似的东西：
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
答案 4 :(得分：1)
如果要开发通用解决方案，可能需要查看DBMS_SQL包。有了它，您可以开发一个包/过程，它将表名作为输入，并通过检查字典中的表结构并动态构建更新来构建基于此的更新。这将是非常简单的前期开发，但未来的维护要少得多，因为如果表结构发生变化，代码会感觉到并适应。此方法适用于您需要使用的任何表。
答案 5 :(得分：1)
根据数据库的复杂程度（表的数量，大小，PK / FK关系的深度，触发器中的其他逻辑），您可能需要查看Oracle Workspace Management。您进行API调用以将表放在工作空间管理下，这会导致Oracle使用可更新视图和其他相应对象替换表，这些对象维护所有行版本的历史记录。
我已经使用了这个并且虽然存在缺点，但审计的一个优点是代码对象都是由Oracle生成的，并且通常假定它们的正确性。
答案 6 :(得分：0)
我唯一一次建议将历史记录存储在与“当前”记录相同的表中，当FK链接到记录必须或可能需要链接到它们时。例如，我见过的一个应用程序有一些FK链接可以链接到记录中的“时间点”，也就是说，如果记录被更新，FK仍会链接到历史记录 - 这是一个设计的重要部分和将历史记录分成第二个表会使它变得更加笨拙。
除此之外，我更希望使用每个表的单独“历史”表来解决跟踪所有更改的业务需求。当然，这意味着更多的DDL，但它极大地简化了应用程序代码，并且您还将从更好的性能和可伸缩性中受益。