假设我们有这些表：
+-------------------------+
| Orphanage |
|-------------------------|
| ID |
| |
+-------------------------+
+-------------------------+ +-------------------------+
| Room | | Orphan |
|-------------------------| |-------------------------|
| ID | | ID |
| Orphanage ID | | Orphanage ID |
| | | |
+-------------------------+ +-------------------------+
+-------------------------+
| Room Movement |
|-------------------------|
| ID |
| Orphan ID |
| From Room ID |
| To Room ID |
| |
+-------------------------+
Room Movement会获得一个新条目。
现在说我想要复制整个Orphanage，并附上所有相关实体。 Room和Orphan非常简单，可以复制 - 保存新的孤儿院以创建ID，并将其传递给Room和Orphan的克隆 - 但Room Movement中的条目稍微复杂一些。我必须为孤儿和房间维护旧的ID到新ID的映射，并为每个插入执行查找。在这个人为的例子中这很简单，但实际上我们在Orphanage下有很多这种关系，以及这些FK关系的嵌套级别。
两个问题：ORM应该处理这个问题吗？这个问题并不是我们的应用程序所特有的，而且似乎使用了正确配置的外键和某种克隆策略＆＃34;系统ORM应该做繁重的工作并以正确的顺序做事。
如果没有，是否有某些地方我可以阅读这个问题并看看其他人如何解决它而不会产生大量的代码？
答案 0 :(得分：1)
看起来你无法理解它们之间的区别 代理键和自然键。您的ID列是代理键， 他们出现在你的模型中的原因是因为他们确定了 ORM和RDBMS更容易完成任务。你的模型应该是 即使你省略它们也是一致的。
显然，你的模型不是因为如果你这样做，那么Orphanage就没有了
属性Room和Orphan仅引用它们的孤儿院
位于等等。
要解决该问题，您需要将自然键添加到模型中。一个
自然键（NK）是一个或多个列的组合
表中独一无二。对于Orphanage，我会添加一列name和。{1}}
NK将是孤儿院的名字（这是合理的
简化，没有两个孤儿院有相同的名字，但在
假设不成立的现实世界：
Orphanage
---------
name
NK: (name)
对于Room，我们可以添加一列room_nr并将其作为NK。但
它还不够，因为很明显两个孤儿院可以有一个房间
相同的room_nr，所以orphanage_id和room_nr的组合
Room
----
orphanage_id
room_nr
NK: (orphanage_id, room_nr)
应该是NK：
Kid同样的理由来弄清楚Kid
---
orphanage_id
name
NK: (orphanage_id, name)
的NK是什么（我喜欢它
表名更好，因为单词＆＃34; orphan＆＃34;和＆＃34;孤儿院＆＃34;太
类似）。我们假设每个孤儿院的名称都是唯一的。所以那里
可能没有两个＆＃34; Joe＆＃34;在同一个孤儿院：
RoomMovement RoomMovement
------------
kid_id
from_room_Id
to_room_id
NK: (kid_id, from_room_id, to_room_id)
：
-- make a new orphanage
insert into Orphanage values ('St. Clara');
-- copy all the rooms
insert into Room(room_nr, orphanage_id)
select
r.room_nr,
(select id from Orphanage where name = 'St. Clara')
from
Room r
join Orphanage o on r.orphanage_id = o.id
where
o.name = 'St. James'
-- copy all the kids in almost the same way.
insert into Kid(name, orphanage_id)
select
k.name,
(select id from Orphanage where name = 'St. Clara')
from
Kid k
join Orphanage o on k.orphanage_id = o.id
where
o.name = 'St. James'
-- copy all the room movements
insert into RoomMovement (from_room_id, to_room_id, kid_id)
select
(select id from Room
where room_nr = r_from.room_nr and orphanage_id = o_to.id),
(select id from Room
where room_nr = r_to.room_nr and orphanage_id = o_to.id),
(select id from Kid
where name = k.name and orphanage_id = o_to.id)
from
RoomMovement rm
join Room r_from on rm.from_room_id = r_from.id
join Room r_to on rm.to_room_id = r_to.id
join Kid k on rm.kid_id = k.id
join Orphanage o_from on o_from.id = k.orphanage_id
join Orphanage o_to on o_to.name = 'St. Clara'
where
o_from.name = 'St. James';
请注意，此表有点不正确。你无法代表一个孩子 被从A房移到B到A然后再回到B.这样 当你不花时间思考时，设计错误就会发生 关于模型的自然键。但对于克隆的问题 孤儿院，这是无关紧要的。
定义了所有自然键后，下一步变得非常容易。说 旧的孤儿院被命名为＃34; St.詹姆斯＆＃34;并且你想克隆它 ＆＃34;圣克拉拉＆＃34;：
{{1}}
答案 1 :(得分：0)
通常，不能根据任何特定的约束顺序构建克隆。 （应用程序关系由表表示; FK虽然称为“关系”是约束。）重构用户可见应用程序状态的重要性是有效的初始状态和一些等效可能的（更不用说实际的）事件序列/从它转换到当前状态。 （甚至可能无法重建那些给定数据库中人们想要的数据。）
然而，重要并不是以这种方式构建克隆，而只是将其设置为某个用户可见的等效应用程序状态 - 根据定义，可以由转换产生。这意味着，复制数据库状态然后启用约束。
系统是一个有限状态机：它具有初始状态，然后通过转换到其他状态。没有理由通过某种特定的“所有关系空”状态的法律过渡来达到每个合法国家。
如果某些非应用程序用户可见的ID在预克隆值中是任意的，那么它们在克隆系统中是任意的。所以你可以复制一下状态。
但是如果那些id不是完全任意的（例如它们可能是克隆实现特定的OID），必须通过合法转换创建（我重复一遍，不是每个约束/ FK而是转换），那么系统必须有一些已知的克隆 - 与代理无关的初始数据库状态和每个当前数据库状态必须确定适合克隆的某些合法（它不必重建实际的）转换序列。这可能确实完全由全表空的初始状态和/或FK图表示。 （尽管在每次过渡后可能必须满足其他限制。）
因此，ORM 可以提供“全表空的初始状态和FK图”版本的帮助。但是应该吗？期望您的数据库状态可以按FK约束元组的顺序从空数据库重建，并且永远不会违反其他约束，这是天真的。约束甚至不一定是非循环的。
此外，非任意应用程序不可见的代理与关联建模相反。您应该拥有与实现无关的数据库版本。在这种情况下，您只需将克隆初始化为整个数据库状态即可。您可能拥有一个特定于实现的相关数据库模式，因为您希望利用关系技术来实现。但要生成有效的OID值，则必须设计任何克隆生成初始状态并转换到您的数据库。
我只关注关系模型和软件设计的基础知识。我不能将您推荐给特定的支持产品或设计参考。特别是ORM通常不了解关系模型，因此不能期望使用正确的抽象来支持您想要做的事情。我希望这条消息有助于您充分而明确地将您的系统设计为特定意义上的“可克隆”。