在代码中而不是在数据库中管理级联删除有什么真正的优势吗？
我将用一些先决条件来设置这个问题，这些先决条件可能会使这个问题变得无关紧要，但就这样吧。
假设我的数据库有一种方法可以进行级联删除，并且我没有尝试为数据库的可能更改进行编码，并且我的数据库模型是这样的，我总是想要级联特定的删除，有没有什么与让数据库通过 DDL 来管理这种级联删除相比，在应用程序代码中管理这种级联删除有何优势？
在我看来，额外的代码、“错过它”的可能性以及错过数据库对其自身功能的内置优化的可能性（可能为零）都是比任何可能的收益更大的缺点。
我错过了什么吗？
I'm going to set up this question with some pre-conditions that may make the question irrelevant, but here goes.
Assuming my database has a way to do cascading deletes and I'm not trying to code for the possible changing of DB, and my DB model is such that I always want a particular delete cascaded, is there any advantage to having to manage this cascading delete in application code rather than having the DB do it via DDL?
It seems to me that the extra code, the possibility of "missing it" there, and the (possibly zero) likelihood of missing out on the DB's built-in optimization of its own features are bigger downsides than any possible gains.
Am I missing anything?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
过去对我来说，DDL Cascade Delete 最大的好处是它是自我维护的。
想象一下这样的场景：
当您添加
TableNew时，通过级联删除，您不需要添加任何代码来处理 TableA 或 TableB 中的删除。通过代码托管删除，您至少有两个位置可以添加新代码。
我发现通过代码管理删除的主要好处是：
1. 它可以阻止意外删除（谢谢外键违规！）
2.它可以处理以下DDL通常无法处理的场景。
The biggest benefit, to me in in the past, of DDL Cascade Delete is that it is self maintaining.
Imagine this scenario:
When you add
TableNew, with a cascade delete, you do not need to add any code to deal with deletions from either TableA or TableB.With code managed deletes, you have at least two places to add new code to.
The main benefits I have found for managing deletes through code are:
1. It stops accidental deletes (Thank you foreign key violations!)
2. It can deal with the following scenario, where DDL often can't.
在我看来，关于删除的策略应该是模型的一部分，因此如果您在创建/设置数据库期间使用 DDL 定义它会更好。
In my opinion the policy about deletes should be part of the model, for this reason is better if you define it using DDL during the creation/setup of your database.