我应该在哪里管理数据库的一致性？

Question

我想了解在代码中管理数据库一致性的优点/缺点，而不是使用SQL功能。

只是解释一下： 一致性意味着如果我有用户，并且每个用户都有专辑并且每个专辑都有图像，则删除用户意味着删除（或软删除）所有专辑和图像。这也可能意味着在每个用户和每个专辑的主键上都有连续ID的图像。

在代码中意味着在我的框架代码中使用“on inserted，deleted，updated”事件（例如Eloquent）

sql功能意味着使用级联，触发器等。

人们抱怨这是基于意见的，但事实并非如此。如果使用mysql shell，那么仅应用代码规则并且没有约束可能会导致不一致 - 这是事实。 此外，如果某人有最佳实践和参考资料的链接，那也很好，我真的很想知道谷歌的开发人员做了什么 - 例如again.not.opinions.but.facts。

编辑：拼写，格式化，根据事实的问题措辞重新开启。

Answer 1

这取决于，但在这里你有一些想法：

• 逻辑放置在DB
  • 开发人员更容易（你把它放在数据库上而忘了）
• 逻辑放在Code
  • 如果您想要纯粹的面向对象，那么该对象应该具有所有业务逻辑。
  • 如果您将来更改持久性电机（例如，面向对象的数据库，您需要在代码中使用此逻辑）
• 放在两个：
  • 对我来说，更好的解决方案是因为将它放在数据库中是一种低成本，对我来说，面向对象的编码不会与持久性（ORM）相结合。

JordiMartínez

Answer 2

Laravel答案

由于您使用laravel以及mysql标记了此问题，因此我将为您提供支持Laravel开发风格的答案。 Laravel通过Artisan支持Eloquent ORM和数据库迁移。这将允许您在代码中保持这种“一致性”，而不是严格地在DB上。

ORM

有大量资源可用于了解ORM是什么以及它是如何工作的。 Laravel使用Eloquent并允许您为模型及其元素强制执行关系和规则。

迁移

使用migrations我们可以使用我们的模型构建我们的数据库，同时在大多数数据库（MySQL与Postgres）之间保持可移植性。

多开发者应用程序

由多个开发人员开发的应用程序需要一种保持同步的方法。如果一个开发人员决定添加具有某些约束的表，则需要将其传达给团队的其他成员。直接向数据库添加规则可能会在与其他团队成员通信时导致问题并且会引起麻烦。相反，使用迁移和ORM来描述正在改变的内容以及原因。迁移将允许任何其他开发人员简单地将他们的数据库“迁移”到最新版本并保持同步。

结论

将点数与其他一些列出的答案进行比较：

• 所有代码仍然在一个地方。迁移和模型是用PHP制作的，并保存在项目仓库中。
• 由于来自ORM和迁移的数据库规则，它已经在应用程序中强制执行。
• 实用，因为Laravel社区内有大量关于这些主题的文档和帮助，可以说是“正式”的方法。
• KISS 这将使一切变得简单，特别是如果您与其他开发人员和环境打交道，因为它非常便携。

Answer 3

这是一个备受争议的话题。与大多数其他开发者一样，我有完全不同的观点（如上所示）。它仍然值得一试：

我将始终管理应用程序代码中所有数据的一致性，并且不使用外键或其他约束。

原因如下：

• 一个代码位置。我的所有逻辑应该在一个地方。如果你将逻辑分布在多个地方，开发人员将来往往会忘记它们，这将严重削弱数据库的一致性。同样的原因，我将永远不会有存储过程btw。

• 应用程序中仍然需要如果在数据库中进行一致性检查，您仍然必须在应用程序中检查相同的约束。您需要这样做以允许应用程序向用户显示错误的错误并强制执行逻辑约束。所以如果你还需要它们，为什么要再次在db中复制相同的规则呢？这导致冗余逻辑，导致容易被遗忘的逻辑，导致瘫痪的一致性。

• 非常不切实际曾经尝试过数据库转储然后将其重新导入数据库吗？你会很难过的。表通常在导入期间违反约束，不同的系统不允许在导入期间忽略约束。通过数据库工具动态管理数据也可能是一个严重的痛苦。因此，它会严重影响您的管理员表现。

是的，无论如何都可能有理由使用约束，但如果它们可以超过三点，它们必须是非常强大的理由。

Answer 4

通常，最好使用像cascade这样的外键约束。它简单，高效且一致。

您的相册表上有类似的内容

FOREIGN KEY (uid) REFERENCES User(id) 
ON DELETE CASCADE 

一旦删除User表中的“id”行，这将删除Album表中引用用户表中特定“id”的所有条目。