我们在数据库中应该做多少工作？

Question

我们在数据库中应该做多少工作？ 我真的很困惑，关于在数据库中应该做多少“工作”，以及相反，在应用程序级别上需要做多少工作？

我的意思不是像将字符串转换为SHA2哈希值这样的明显事情应该在应用程序级别完成，而不是在数据库级别完成。

但是更模糊的东西，包括但不限于“我们应该检索4列数据并在应用程序级别进行大写/连接，还是应该在数据库级别完成这些操作并将计算结果发送到应用程序级别？”

如果您能列出任何其他例子，那就太好了。

- Timothy

---

在数据库中完成“数据库工作”，即高效地选择和存储数据。 - Mitch Wheat

Answer 1

这取决于你的需求。我喜欢在数据库中执行业务逻辑，而其他人则坚决反对。

你可以在SQL中使用触发器和存储过程/函数。

MySQL链接： http://dev.mysql.com/doc/refman/5.5/en/triggers.html http://www.mysqltutorial.org/introduction-to-sql-stored-procedures.aspx http://dev.mysql.com/doc/refman/5.5/en/stored-routines.html 我之所以选择在触发器和存储过程中执行业务逻辑，是因为...

请注意，我不是在谈论将数据库结构弯曲到业务逻辑方面，我是在谈论将业务逻辑放入触发器和存储过程中。

1. 它集中了你的逻辑，数据库是一个中心位置，所有的东西都必须通过它。如果你的应用程序有多个插入/更新/删除点（或者你有多个应用程序），你需要多次进行检查，如果你在数据库中进行检查，你只需要在一个地方进行检查。
2. 它简化了应用程序，例如，您只需添加一个成员，数据库将确定该成员是否已知并采取适当的操作。
3. 它隐藏了数据库的内部，如果您在应用程序中执行所有逻辑，则需要对应用程序中的每个细节有精细的了解。如果您使用数据库代码（触发器/存储过程）来隐藏它，您不需要在应用程序中了解每个数据库细节。
4. 它使重组数据库更容易。如果您在数据库中具有逻辑，您可以只更改表格布局，用黑洞表格替换旧表格，在其上放置触发器，让触发器将更新发送到新表格，您的应用程序甚至不需要知道数据库已更改，这使得旧的应用程序可以保持不变，而新的应用程序可以使用改进的数据库布局。
5. 某些事情在SQL中更容易
6. 某些事情在SQL中更快
7. 我不喜欢在我的应用程序中使用（大量和/或复杂的）SQL代码，我喜欢将SQL代码放在存储过程/函数中，并尽量只在我的应用程序代码中放置简单的查询，这样我就可以编写解释我的应用程序意图的代码，让数据库层来完成繁重的工作。

有些人强烈反对这种方法，但我发现这种方法对我很有效，并且大大简化了我的应用程序的调试和维护。

- Johan

Answer 2

通常，期望从数据库中获取到的只有"数据"是一个良好的实践。它由应用程序应用业务/领域逻辑并理解检索到的数据。在应用程序层面强烈建议执行以下操作：

1）格式化日期 2）应用数学函数，如插值/外推等 3）动态排序（基于列）

然而，有时情况需要在数据库层面完成一些操作。

- Akhil

Answer 3

在我看来，应用程序应该使用数据，而数据库应该提供这些数据，并且应该有明确的关注点分离。因此，数据库根据请求的条件提供排序、排序和过滤的记录，但是由应用程序将一些业务逻辑应用于这些记录并将它们“转换”为对用户有意义的东西。

例如，在我之前的公司，我们开发了一个用于工作时间计算的大型应用程序。在这种应用程序中，一个明显的功能是跟踪员工的休假天数 - 每年有多少天员工可以休假，他使用了多少天，还剩下多少天等等。基本上，我们可以编写一些触发器和过程，自动更新这些列。因此，当员工获得批准休假天数时，从他的“休假池”中取出他申请的天数，并添加到“已用休假天数”中。这很容易，但我们决定在应用程序级别上明确表示它，很快我们就会发现我们做得很好。应用程序必须符合劳动法规定，很快就会发现并非所有员工的休假天数都是平等计算的，有时候休假日可能根本不是休假日，但这不是重点。如果我们将这个“简单”的操作放在数据库中，我们必须对与休假天数相关的逻辑进行每一个小改变的版本控制，这将使我们在客户支持领域陷入困境，因为除了在数据库结构发生“突破性”变化的情况下需要更新数据库外，只需更新应用程序即可。

- grapkulec

Answer 4

在我的经验中，我发现许多应用程序都是从一组简单的表和一些存储过程开始提供基本功能。这种方法非常有效，通常可以获得高性能并且易于理解，同时也减少了对复杂中间层的需求。

然而，应用程序会不断增长。大型数据驱动应用程序拥有数千个存储过程并不罕见。如果加入触发器，那么除了原始开发人员（如果他们仍在工作），其他人维护起来就非常困难了。

我要为将大部分逻辑放在数据库中的应用程序说句话——当你拥有一些优秀的数据库开发人员和/或你拥有无法更改的遗留模式时，它们可以很好地工作。我之所以这样说，是因为ORM可以在你让它们控制模式时（如果没有，你通常需要做很多琢磨才能让它正常工作）轻松处理应用程序开发的这一部分痛苦。

如果我正在设计一个新的应用程序，那么我通常会选择由我的应用程序域（其设计将在代码中）指定的模式。我通常会让ORM处理对象与数据库之间的映射。当涉及到数据访问时，我会将存储过程视为规则的例外情况（在sproc中进行报告比试图让ORM高效地生成复杂输出要容易得多）。

最重要的是要记住，当涉及到设计时，没有所谓的“最佳实践”。作为开发人员，你需要在你的设计背景下权衡每个选项的利弊。

- David Neale