数据库中域逻辑的时代结束了吗？[关闭]

我最近偶然发现了2016年的这一观点，说数据库中仍然存在领域逻辑的情况。

我认为这完全是过时的。我只是想知道那家伙是否​​仍然生活在90年代，或者这真的是真的。保留旧系统。

由于安全性要求，在数据库中包含域逻辑该怎么办？那真的是一件事吗？

如今，程序员似乎非常教条地思考，特别是当他们阅读其他人在博客中发表的想法时。

以Bob Martin的Clean Coding博客为例。作为一般观察，我发现鲍勃·马丁的著作相当清晰明了，所以让我感到困惑的是，人们不断被他所写的东西（例如SOLID原理）所迷惑。当他们可能应该做的只是简单地努力编写更好的代码并首先获得一些经验，以便他们阅读时，他们就沉迷于“单一职责”应该是什么，或者为什么有些班级违反了Liskov的原理。博客有一定的背景。

基本上，您要说的是数据库应包含表和数据，仅此而已。但是数据库非常适合于做某些特定的事情……好，数据库擅长。

本文引用了以下内容：

• 数据完整性和验证（例如，空约束和唯一约束）
• 行级安全
• 使用存储过程编写API
• 计算余额
• 向数据库提问（即查询和报告）
• 避免诸如N + 1之类的ORM问题

作为适合放入数据库的东西。我碰巧同意他的看法。

您没有将业务逻辑（通常）放入数据库的原因：

• 供应商锁定
• 您的数据库不是中央机构
• 您的团队不以为然
• 劣质的工具。

但是这些事情通常仅适用于数据库并非唯一适合的那些技术，工具和培训。

因此，与软件开发中的任何其他技术一样，这取决于。您评估替代方案，然后根据您认为对特定应用程序可能采取的最佳行动方案做出决定。

马和马车的时代已经过去，但是您仍然可以购买马车的马鞭。

为什么？当汽车更快，维护更便宜并且忽视它们不会引起人道社会的来访时，为什么马车仍然存在？

因为有时候，除了受欢迎的原因之外，您还有其他原因要做某事。

您应该学习的是数据库中的域逻辑为什么会导致问题以及任何人可能从中摆脱出来的原因。然后下定决心。

我个人的看法：

域逻辑与行为有关。数据库是关于持久性，关系以及数据的。当您看到这种方式时，业务规则不应出现在数据库中。

另一方面，谁说数据库无法运行？我已经使用Filemaker建立了办公数据库。人们称它为数据库，但实际上它也是整个应用程序开发环境。一切都无缝集成到一个数据库中。

通常在极端观点之间发现智慧。我毫不怀疑，无论是可以工作。尝试找到中间位置时，很容易跟随人群。在这里，我将对此警告。

将域逻辑保留在数据库中的系统可以正常工作。将域逻辑排除在数据库之外的系统可以正常工作。一个在两个地方都混有域逻辑的系统会让我发疯。我不知道在哪里放新行为。我不确定在哪里可以找到旧的行为。

如果您仍然不能决定掷硬币，则可以将其作为任何特定项目的福音。据我所知，硬币与其他任何人一样，都知道最好。

我曾经遇到过一个案例，那就是在业务层解决它会成为真正的性能杀手。

我们的应用程序OO安全概念由角色和组组成。两者都是递归结构。我们编写了一个存储过程，用于解决用户对域对象的权限。

倒退到数据库逻辑的需求确实很少。但是在这种情况下，我决定采用这种方式。但是，您始终必须考虑的是：放弃抽象。一旦在数据库中有了业务逻辑，就很难更改持久层。所以要非常小心。