我正在尝试决定如何最好地为我的 Rails 应用程序设置（如果有的话）外键约束。我有一个模型Response that belongs_to a Prompt。我想用:dependent => :destroy摧毁每一个Response属于已删除的Prompt我正在尝试决定应该对外键施加什么删除约束。
简而言之，我想要关于如何最好地利用依赖对象上的 destroy 方法和外键约束的建议，以确保 cruft 不会累积并反映所存储数据的逻辑结构。几个早期的问题，例如我应该使用 ON DELETE CASCADE、 :dependent => :destroy 还是两者都使用？ https://stackoverflow.com/questions/1189970/should-i-use-on-delete-cascade-dependent-destroy-or-both and Rails：删除级联与依赖销毁 https://stackoverflow.com/questions/12556614/rails-delete-cascade-vs-dependent-destroy?rq=1问哪个更好，但他们并没有真正说明这两个选择如何相互作用以及它们以什么顺序触发，或者在这一点上似乎很模糊。
在我看来，这些考虑因素似乎分为几个部分：
- Does
:dependent => :destroy在从数据库中删除父对象之前，首先对依赖对象调用 destroy，因此即使我使用级联删除，仍会在这些对象上调用 destroy 吗？
Does :dependent => :destroy在从数据库中删除父对象之前（或在事务中）从数据库中删除依赖对象？换句话说，如果我将级联设置为无效，数据库最终会在子对象被删除之前浪费地无效化子对象上的引用吗？
删除是否是由于原始销毁和链接而发出的:dependent => :destroy选项包含在事务中，或者如果我不设置级联删除，不幸的是定时崩溃会在数据库中留下痕迹吗？
- 终于会
:dependent => :destroy如果我使用限制作为外键 on_delete 选项，确保从数据库中删除父对象？
With dependent: :destroy在事务中，rails 首先销毁所有依赖项，然后才删除记录本身。
可能存在竞争条件：如果在 Rails 读取集合以进行销毁之后添加了依赖记录，但尚未删除父记录 - 它可能会被遗留下来。下面我们将这些称为“竞争条件记录”。
是的，你可以使用dependent: :destroy and on delete cascade，这样可以删除一些子项（竞争条件的子项）而无需回调。如果回调是强制性的 -on delete restrict结合一些锁定和显式子项删除可能会更好。
这有点像validates :some_field, uniqueness: true最好有唯一索引作为支撑，只有数据库本身才能保证数据的一致性。
由于父级最后被删除，on delete nullify不会妨碍（你会得到无效的竞争条件记录）
有事务包装所有删除，只能留下竞争条件记录
on delete restrict over dependent: :destroy只会针对竞争条件记录触发（并回滚整个事务），但如果没有竞争条件 - Rails 会很乐意删除所有内容。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
