数据库和深拷贝答案

【问题标题】：Databases and Deep Copy数据库和深拷贝
【发布时间】：2010-07-15 21:06:08
【问题描述】：

如果我发现自己想要对存储在我的关系数据库中的对象进行深层复制，我是否必然在架构上做了一些根本错误的事情？这是我提出的另一个（更详细的）问题的不同角度，但没有得到太多回应，称为Copying Relational Table Data。

【问题讨论】：

标签： database-design orm

【解决方案1】：

不一定。我自己已经成功地实现了版本控制方案。基本上可以对整个图进行版本控制（使用一个比较键，其中一个键是事物 id，另一个是版本号），我们可以轻松访问所有以前版本的图或子图。

需要明确的是，DB Architect 推荐了这个方案；他的意见很重要，解决方案不是我的首选。但最终效果非常好。

【讨论】：

【解决方案2】：

通常，如果您复制父对象，您只想复制对子对象的引用，而不是对象本身。但是，在某些情况下，例如在给定时间点保留对象的状态，需要复制子对象。所以，为了回答你的问题，这个场景应该让你停下来思考，但并不一定意味着你做错了什么。

【讨论】：

【解决方案3】：

我对此的看法是，如果您需要数据库对象的弹性克隆，那么您最好的选择是执行深层复制 - 至少复制所有可能在未来某个时间点发生变化的项目。除了实现一些写时复制样式的“克隆”之外，我认为没有其他选择，虽然在某些情况下它可能是正确的，但会引入大量额外的逻辑和复杂性。

【讨论】：

【解决方案4】：

这取决于您的关系表代表什么，以及您将哪些实体组合在一起以构建“业务对象”。例如，如果您有一个内容管理系统的关系模型，其中包含一个表“Postings”和一个表“Text_lines”，其中每个 Posting 都包含一个文本行列表，那么您的业务对象“Posting”的有效副本很可能是“Postings”实体及其所属 Text_lines 实体的深层副本。

另一方面，如果有两个表“Department”和“Employees”，一个部门的正确副本很可能不是深层副本，（至少，如果每个员工在某个时间点与一个部门关联时间）。在关系数据库方案中，这些差异通常与分配给关系的引用完整性检查密切相关。可以使用具有“ON DELETE CASCADE”完整性的外键约束对关系“Postings”->“Text_lines”进行建模（当然，如果您的数据库支持）。但是，“部门”->“员工”不应该有这样的“ON DELETE CASCADE”检查。

【讨论】：