现在验证 FK 还是稍后恢复？答案

【问题标题】：Validate FK now or recover from later?现在验证 FK 还是稍后恢复？
【发布时间】：2010-01-09 19:57:02
【问题描述】：

什么是更被接受的 Rails 方法？

验证创建/更新时是否存在外键

或

当我们想使用不存在的外键时“损坏控制”？

初始验证在行创建/更新方面需要更多资源，当我在代码中系统地创建行时（即不是用户生成的），甚至可能是多余的。但是，我可以流畅地编写我的业务逻辑，而不必担心遇到错误的外键。

另一方面，损坏控制允许快速创建和更新，当然，我的逻辑中还有更多检查和恢复。

你能想到其他的优点和缺点吗？也许除了这两个教义之外，还有更多的选择。

有经验的 Rails 开发人员如何处理这个问题？

【问题讨论】：

正确的数据对我来说更有价值 - 应用程序会来来去去，当您需要获取坏数据时，它可以节省编写错误数据的时间。
+1 关于使用 FK，即使是在模型中具有数据验证的 Rails 也是如此。您永远不知道其他应用何时需要能够访问您的数据库，因此至少使用 FK 在您的数据库中保持完整性（而不是业务规则）是明智之举。

【解决方案1】：

如果提前验证是指执行额外的数据库请求只是为了验证密钥的存在，我会说不要这样做。我们到处使用 FK，几乎从未遇到过问题，尤其是在创建或更新时。如果它确实失败了，那可能是一件好事，与验证不同，你可以做一些事情，如果你只是尝试向不再存在的对象添加关联，这对我来说似乎是一个很好的错误理由。

如果您有特别不稳定的实体，例如在实例化和尝试将其保存在 FK 之间的实例可能经常被删除，那么在这种特殊情况下它可能是值得的，但作为我不会的一般指南。

我也经常在使用逻辑删除删除的表之间使用 FK（例如，acts_as_paranoid，设置 deleted_at 标志而不是实际删除行），这也缓解了 FK 失败的问题，我发现它非常有帮助至少在我的应用中使用策略。

【讨论】：