在代码或数据库中传播删除？答案

【问题标题】：Propagated delete in code or database?在代码或数据库中传播删除？
【发布时间】：2009-02-26 21:07:08
【问题描述】：

我正在开发一个具有一些数据关系的 iPhone 应用程序（例如作者 -> 书籍）。当用户从应用程序中删除作者对象时，我有一些 SQLite 触发器在删除时运行，以从数据库中删除具有与作者主键匹配的外键的任何书籍。

我还使用触发器在创建新项目时插入一些数据。

我不禁感到这可能是糟糕的设计，或者会导致一些我没想到的问题。也就是说，当数据库具有内置功能来处理它时，我是否应该依靠我的应用程序中的代码来处理像这样传播删除？

你说什么？

【问题讨论】：

【解决方案1】：

没错。尽可能使用数据库的内置功能。至少尝试这样开始，只有在事情真正需要时才妥协。

【讨论】：

【解决方案2】：

我会利用数据库的功能来确保关系完整性，尤其是在更新/删除方面。在某些情况下，我可能会使用触发器来插入一些额外的数据（想到审计），尽管我倾向于避免这种情况并从我的应用程序中插入所有数据。但是，如果您要进行多次插入，请确保将其全部包装在一个事务中，以免最终出现可能导致关系完整性丢失的部分插入。

【讨论】：

【解决方案3】：

我喜欢使用数据库内置功能的想法（我不熟悉它的工作原理）。但如果我一年后回到代码中，我会担心，我会记得它是如何工作的吗？（鉴于代码不在我面前）。

我想如果你添加很多cmets来提醒自己现在是如何工作的，如果将来出现任何问题，至少你不需要在需要进行一些调试时重新学习数据库功能。

【讨论】：

【解决方案4】：

您比我领先几步：我最近了解了如何使用触发器来做这些事情，我很想自己使用它们。

根据此处的其他答案，这似乎是一个哲学选择。使用触发器或代码可能会很好，但最好保持一致。所以不要在一个表上使用触发器来级联删除，然后在另一个表上使用 C 代码。

由于您标记了问题 iphone，我认为最重要的区别是 C 代码与触发器的相对性能。您可能必须同时编写代码并进行试验以确定差异（如果有）。

我想到的另一件事是，在我在 thedailywtf.com 上阅读的所有恐怖故事中，大约有一半似乎涉及数据库触发器。

【讨论】：

【解决方案5】：

不幸的是，SQLite 不支持删除级联等。来自 SQLite 文档：

解析外键约束但不强制执行。但是，可以使用触发器来实现等效的约束实施。 SQLite 源代码树包含用于读取 SQLite 数据库、分析外键约束并自动生成适当触发器的 C 程序的源代码和文档。

对触发器有一些支持，但还不完整。缺少的子功能包括 FOR EACH STATEMENT 触发器（目前所有触发器都必须是 FOR EACH ROW）、表上的 INSTEAD OF 触发器（目前 INSTEAD OF 触发器只允许在视图上使用）和递归触发器 - 自行触发的触发器。

因此，使用 SQLite 对删除级联等进行编码的唯一方法需要触发器。亲切的问候，

【讨论】：

【解决方案6】：

代码进入您的应用程序。

触发器是代码。该功能在您的应用程序中。不在数据库中。

我认为数据库应该用于数据，而不是处理。我认为应用程序应该用于处理，而不是数据。

数据库处理功能只是搅浑水。

【讨论】：

我不同意。有用于确保关系完整性的数据库机制，它们应该在适当的地方使用——比如级联删除。至于插入额外的数据，这将取决于。如果在应用程序中完成，请确保将两个插入包装在一个事务中。
@tvanfosson：声明性参照完整性有一定的价值。级联删除、触发器等通常会失控。似乎总是有比他们解决的问题更多的问题。一些技术性的和一些组织性的。
Decalrative 参照完整性具有巨大的价值。它有助于查询优化器并保证数据是真实世界的正确表示。如果你不愿意学习和理解数据库编码，那就交给专业的人吧;)
@David Aldridge：作为一名数据架构师，我在每个模式中都使用声明性 RI，因为它增加了价值。它对查询优化有多大帮助是值得商榷的，因为索引的帮助远远超过 RI。
例如，它可以通过指示表 A 中的每一行保证表 B 中恰好有一个连接行（其中 A 具有到 B 的外键）来帮助优化。这样可以更好地估计结果基数...