假设我在数据库中有一条记录,并且管理员和普通用户都可以进行更新。
任何人都可以提出一个好的方法/体系结构来控制该表中的每个更改的版本,从而可以将记录回滚到以前的修订版。
假设我在数据库中有一条记录,并且管理员和普通用户都可以进行更新。
任何人都可以提出一个好的方法/体系结构来控制该表中的每个更改的版本,从而可以将记录回滚到以前的修订版。
Answers:
假设您有一个FOO
可供管理员和用户更新的表。大多数时候,您可以针对FOO表编写查询。快乐的时光。
然后,我将创建一个FOO_HISTORY
表。这具有表的所有列FOO
。主键与FOO相同,外加一个RevisionNumber列。有一个从FOO_HISTORY
到的外键FOO
。您可能还会添加与修订有关的列,例如UserId和RevisionDate。以越来越多的方式在所有*_HISTORY
表中填充RevisionNumbers (即从Oracle序列或等效表中)。不要只依赖在一秒钟内进行一次更改(即不要放入RevisionDate
主键中)。
现在,每次更新时FOO
,就在您进行更新之前,将旧值插入FOO_HISTORY
。您需要在设计的某个基本级别上执行此操作,以使程序员不会意外遗漏此步骤。
如果要从中删除行,则FOO
有一些选择。级联并删除所有历史记录,或者通过将其标记FOO
为已删除来执行逻辑删除。
当您对当前值非常感兴趣并且仅对历史记录感兴趣时,此解决方案是不错的选择。如果您始终需要历史记录,则可以输入有效的开始日期和结束日期,并将所有记录保留在FOO
其内。然后,每个查询都需要检查这些日期。
There is a foreign key from FOO_HISTORY to FOO'
:不好的主意,我想从foo中删除记录而不更改历史记录。在正常使用情况下,历史记录表应仅插入。
在BI世界中,您可以通过将startDate和endDate添加到要版本化的表中来实现此目的。当您将第一条记录插入表中时,将填充startDate,但endDate为null。当插入第二条记录时,您还用第二条记录的startDate更新了第一条记录的endDate。
当您要查看当前记录时,请选择endDate为null的记录。
有时称为2型缓慢变化尺寸。另请参见TupleVersioning
只是想添加一个解决此问题的好方法是使用Temporal数据库。许多数据库供应商开箱即用或通过扩展提供了此功能。我已经在PostgreSQL中成功使用了时态表扩展,但是其他人也有。每当您更新数据库中的记录时,数据库也会保留该记录的先前版本。
您没有说什么数据库,我也没有在post标签中看到它。如果是针对Oracle的,我可以推荐Designer中内置的方法:使用日记表。如果是用于其他任何数据库,那么我基本上也建议采用相同的方式...
如果您想在另一个数据库中复制它,或者如果您只是想了解它,那么它的工作方式是对于一个表也创建了一个影子表,只是一个普通的数据库表,具有相同的字段规格,以及一些其他字段:例如上次执行的操作(字符串,典型值“ INS”表示插入,“ UPD”表示更新和“ DEL”表示删除),执行操作的日期时间以及执行操作的用户ID它。
通过触发器,对表中任何行的每个操作都会在日记表中插入一个新行,其中包含新值,执行了什么操作,何时以及由哪个用户执行。您永远不会删除任何行(至少最近几个月不会删除)。是的,它会变得很大,可以轻松地行达数百万行,但是您可以轻松地自日志记录开始或旧的日志行被最后清除以及谁进行了最后更改以来的任何时间跟踪任何记录的值。
在Oracle中,您需要的所有内容都将作为SQL代码自动生成,您所要做的就是编译/运行它。它带有一个基本的CRUD应用程序(实际上只有“ R”)来检查它。
我也在做同样的事情。我正在为课程计划建立数据库。这些计划需要原子更改版本控制灵活性。换句话说,对课程计划的每次更改(无论大小)都必须允许,但旧版本也必须保持完整。这样,课程创建者可以在学生使用课程计划时对其进行编辑。
它的工作方式是,一旦学生完成一堂课,他们的成绩就会附在他们完成的版本上。如果进行更改,其结果将始终指向其版本。
这样,如果删除或移动课程标准,其结果将不会更改。
我目前这样做的方式是通过在一个表中处理所有数据。通常,我只有一个id字段,但是在这个系统中,我使用的是id和sub_id。通过更新和删除,sub_id始终与该行保持一致。ID是自动递增的。课程计划软件将链接到最新的sub_id。学生成绩将链接到ID。我还提供了一个时间戳,用于跟踪更改发生的时间,但是没有必要处理版本控制。
经过测试,我可能会改变的一件事是,我可能会使用前面提到的endDate null想法。在我的系统中,要找到最新版本,我必须找到max(id)。另一个系统只是寻找endDate = null。不知道收益是否超出了另一个日期字段。
我的两分钱。
而@WW。答案是一个好答案。另一种方法是创建一个版本列,并将所有版本保留在同一表中。
对于一个表方法,您要么:
outer join
。outer join
使用修订号的方法的示例SQL 为:
SELECT tc.*
FROM text_content tc
LEFT OUTER JOIN text_content mc ON tc.path = mc.path
AND mc.revision > tc.revision
WHERE mc.revision is NULL
AND tc.path = '/stuff' -- path in this case is our natural id.
坏消息是上述要求一个outer join
外部连接可能很慢。好消息是,从理论上讲,创建新条目的成本较低,因为您可以在一次写入操作中完成该操作而无需事务(假设数据库是原子的)。
对其进行新修订的示例'/stuff'
可能是:
INSERT INTO text_content (id, path, data, revision, revision_comment, enabled, create_time, update_time)
(
SELECT
(md5(random()::text)) -- {id}
, tc.path
, 'NEW' -- {data}
, (tc.revision + 1)
, 'UPDATE' -- {comment}
, 't' -- {enabled}
, tc.create_time
, now()
FROM text_content tc
LEFT OUTER JOIN text_content mc ON tc.path = mc.path
AND mc.revision > tc.revision
WHERE mc.revision is NULL
AND tc.path = '/stuff' -- {path}
)
我们使用旧数据进行插入。如果说您只想更新一列并避免乐观锁定和/或事务,则此功能特别有用。
标志方法和历史记录表方法要求 插入/更新两行。
outer join
修订号方法的另一个优点是,您以后总是可以使用触发器来重构为多表方法,因为触发器本质上应该执行上述操作。
阿洛克建议 Audit table
在上面,我想在我的帖子中进行解释。
我在项目中采用了这种无模式的单表设计。
架构:
该表可以一次保存所有表的历史记录,而一条记录中包含完整的对象历史记录。该表可以使用触发器/挂钩来填充,数据在触发器/挂钩中更改,并存储目标行的新旧值快照。
具有这种设计的优点:
与此设计的缺点: