我和一些同事讨论了存储历史数据的最佳方法.目前,对于某些系统,我使用单独的表来存储历史数据,并保留当前活动记录的原始表.所以,假设我有桌子FOO.在我的系统下,所有活动记录将进入FOO,所有历史记录将进入FOO_Hist.FOO中的许多不同字段可以由用户更新,因此我希望保持对更新的所有内容的准确帐户.除了自动递增的HIST_ID之外,FOO_Hist保存与FOO完全相同的字段.每次更新FOO时,我都会在FOO_Hist中执行一个插入语句,类似于:insert into FOO_HIST select * from FOO where id = @id.
我的同事说这是糟糕的设计,因为出于历史原因我不应该有一个表的精确副本,而应该只是在活动表中插入另一条记录,并带有一个标志,表明它是出于历史目的.
是否有处理历史数据存储的标准？在我看来,我不想把我的所有历史记录都放在同一个表格中,因为它可能超过一百万条记录(我在考虑长期).
你或你的公司如何处理这个问题？
我正在使用MS SQL Server 2008,但我想保持任何DBMS的通用和任意的答案.
要求:
谷歌发现了这些:
编辑:
没有应用程序,只有库.
(与版本化数据库模式无关)
与数据库接口的应用程序通常具有由来自许多表的数据组成的域对象.假设应用程序支持这些域对象的CVS意义上的版本控制.
对于某些仲裁域对象,您将如何设计数据库模式来处理此要求？有经验可以分享吗？
在阅读了很多关于保持页面更改历史记录或如何版本控制数据库中的记录(例如)的SO问题之后,我找不到真正优雅的解决方案来完成工作.
现在,让我们尝试尽可能清楚地解释我们需要什么,对于这个简单的修订系统,允许注册用户发布一些文章,其他用户提交那些文章的修订版,然后一些版主用户检查那些修订版.
MySQL数据库
该数据库包含一个文章表,其中包含以下简化字段:
ARTICLE(id, id_user, title, content, date);
要实现修订/历史版本,我想我们将有下表:
REVISION(id, id_article, revision_id_user, id_moderator, revision_date,
revision_title, revision_content, revision_description, revision_check);
与关系: ARTICLE 0,n <---> 1,1 REVISION
工作流程
用户创建一个ARTICLE,它被插入ARTICLE表中(太棒了!)
另一个用户对此进行了更新ARTICLE,此更新记录在REVISION表中,并为主持人用户排队.(revision_check=0).
主持人用户验证REVISION(revision_check=1),然后ARTICLE(content)获取REVISION(revision_content)值.
我的问题
这个工作流程似乎是一个很好的方法吗？因为,我看到一个错误:如果有几个REVISIONs ARTICLE:
REVISION还是原始内容ARTICLE？REVISION在未检查最后一个时,不能提交其他内容.有没有办法记录轻型版本？那么,是否可以REVISION通过SQL,PHP或js比较函数在表中插入更新的内容？如何像SO一样显示它呢？因为我担心REVISION桌子会很重.
额外奖励:怎么样？
任何想法,链接,源代码,插件(MySQL,PHP 5和JS/Jquery)都会受到极大关注.
我有一个CMS系统,可以跨表格存储数据,如下所示:
Entries Table
+----+-------+------+--------+--------+
| id | title | text | index1 | index2 |
+----+-------+------+--------+--------+
Entries META Table
+----+----------+-------+-------+
| id | entry_id | value | param |
+----+----------+-------+-------+
Files Table
+----+----------+----------+
| id | entry_id | filename |
+----+----------+----------+
Entries-to-Tags Table
+----+----------+--------+
| id | entry_id | tag_id |
+----+----------+--------+
Tags Table
+----+-----+
| id | tag |
+----+-----+
我正在尝试实施修订系统,有点像SO.如果我只是因为Entries Table我正在计划在一个单独的表中保留该表的所有更改的副本.因为我必须为至少4个表(TAGS表不需要修改)这样做,这似乎不像一个优雅的解决方案.
你们会怎么做？
请注意,元数据表是以EAV(实体属性值)建模的.
先感谢您.
mysql database version-control revision entity-attribute-value
我想在数据库中存储博客文章.我认为拥有不同版本的数据会很不错,就像版本控制对文本文件一样.
所以,我想它就像一个表中的一行,有版本控制.因此,例如,您可以检索该行的最新版本或先前版本.你甚至可以从那一行开始分支.
有这样的事吗？
可能有用的信息:我目前正在使用Python,Django和MySQL.我正在试验MongoDB
编辑为清晰/更多上下文:我正在寻找一个更适合行的"版本控制"而不是数据库的解决方案; 我对分支整个数据库并不感兴趣.例如,我将能够在2011年1月1日和2010年1月1日查询博客文章的内容(无需切换数据库).
我正在开发一个项目,我必须在每个表中添加一种数据版本控制或历史记录功能.基本上,我们必须跟踪数据库中的每个插入或更改,以便可以轻松回滚或查看每个表中的数据的先前版本.
我的项目经理设想这样做的方法是为每个表添加一些新的颜色.主要特征是名为"版本"的coloumn.每次更新时,都没有真正更新,旧行仍然存在但是新行添加到表中,其中"version"的值递增.
要显示当前数据,我们只使用一个视图,该视图仅显示每种类型的版本号最高的行.
虽然这在不同版本之间来回移动时效果很好,但我遇到了这种方法的问题.对于表之间存在的任何关系,我们需要定义外键,外键只能引用另一个表中的唯一字段.既然我们保留了同一行的多个版本(具有相同的'Id',因为它与我们的应用程序有关,它基本上是相同的数据)我们不能再使用另一个表的'Id'作为外键一张桌子.
我们为每一行使用唯一的主键字段,但这对于标识符是无用的,因为几行基本上是同一事物的不同版本.我们可以手动跟踪每种条目的最新版本,并在每次更改时更新相应的外键关系,但这看起来像很多工作,我不确定它是否总能工作(例如,恢复到以前的版本一个条目可能导致外键引用其他表中另一个条目的旧版本和不可用版本.)
我知道还有其他方法可以保存数据库更新的历史记录(例如,通过为每个表使用单独的历史表),但我在这个项目中坚持这种方法.是否有一些更明显的方法来处理这样的表之间的关系,我错过了？
注意:我正在使用MS SQL Server 2008 R2.
我正在阅读这篇文章以实现表的记录级版本控制。我注意到该架构涉及历史表的使用。但是，我的场景不需要回滚，而是检索时间点记录。这是我尝试使用单个表进行版本控制的设计。请注意，这是一个简单的表数据（没有约束、索引等）。我打算基于 id 建立索引，因为这涉及列上的 group by 子句。
例如，我有一个表 Test ，其中
id 是标识符，
modstamp 是数据的时间戳（绝不为空）
除了上面的列外，该表还将包含簿记列
local_modstamp 是更新记录的时间戳
del_modstamp 是删除记录的时间戳
在备份期间，所有记录均从源获取并插入到记录具有值 local_modstamp = null 和 del_stamp = null 的位置。
id |modstamp |local_modstamp |del_modstamp |
---|---------------------------|---------------|-------------|
1 |2016-08-01 15:35:32 +00:00 | | |
2 |2016-07-29 13:39:45 +00:00 | | |
3 |2016-07-21 10:15:09 +00:00 | | |
获得记录后，处理数据的场景如下（假设参考时间[ref_time]是进程运行的时间）：
正常插入。
更新：使用 local_modstamp = ref_time 更新最新记录。然后插入新记录。查询将是：更新测试集 local_modstamp = 其中 id = 且 local_modstamp 不为空且 del_modstamp 不为空 插入测试值(...)
删除：用 del_modstamp = ref_time …
对源代码(如subversion)使用版本控制系统是有意义的,因为它允许您退出错误,审核更改,制作无痛快照,准确发现出错的地方,以便您可以改进您的流程等.理由是对业务数据进行更改跟踪是有意义的,许多系统都这样做.
关于如何在普通数据库之上实现它,已经有一些问题:
对于一个如此有用和受欢迎的功能,我们都需要重新发明轮子似乎很奇怪.是否有任何现有的数据库实现已经解决了这个问题？我想象这样的系统会扩展SQL语法以便于查询历史记录.