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

Question

我们应该在数据库中做多少工作？ 好吧我真的很困惑，确切地说应该在数据库中完成多少“工作”，以及在应用程序级别需要完成多少工作？

我的意思是我不是在谈论明显的东西，比如我们应该在应用程序级别而不是数据库级别将字符串转换为SHA2哈希值。

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

如果你能列出更多其他例子，那就太棒了。

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. 这样可以更轻松地恢复数据库如果你的数据库中有逻辑，你只需更改一个tablelayout，用黑洞表替换旧表，在其上放一个触发器然后让它触发器对新表进行更新，您的应用甚至不需要知道数据库已更改，这样可以使旧版应用程序保持不变，而新应用程序可以使用改进的数据库布局。
5. SQL中的一些内容更容易
6. 有些事情在SQL中运行得更快
7. 我不喜欢在我的应用程序中使用（许多和/或复杂的）SQL代码，我喜欢将SQL代码放在存储过程/函数中并尝试仅放置简单查询在我的应用程序代码中，这样我就可以编写代码来解释我在我的应用程序中的含义，并让数据库层完成繁重的工作。

有些人对此表示强烈反对，但这种方法对我来说效果很好，并且简化了我的应用程序的调试和维护。

Answer 2

通常，从数据库中仅预期“Data”是一种很好的做法。它应用于应用业务/域逻辑并理解检索到的数据。强烈建议在应用层中执行以下操作：

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

但是，某些情况下某些情况下在数据库级别上几乎无法完成任务。

Answer 3

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

例如，在我以前的公司，我们致力于大型应用程序的工作时间计算。这类应用程序中的一个显而易见的功能是跟踪员工的休假日 - 员工每年有多少天，他使用了多少，剩下多少等等。基本上我们可以写一些自动更新这些列的触发器和程序。因此，当员工休假时，他申请的天数是从他的“度假池”中取出并添加到“休假日”。非常简单的东西，但我们决定在应用程序级别和男孩明确表示，很快我们很高兴我们这样做了。申请必须符合劳动法，并且很快就发现不是所有员工的假期都是平等计算的，有时休假日可能不是休假日，但这是不重要的。如果我们把这个“简单”的操作放在数据库中，我们就必须对度假日相关逻辑的每一点改动都对我们的数据库进行版本化，这会导致我们直接进入客户支持领域，因为它可以只更新应用程序无需更新数据库（当然，数据库结构发生变化的明确“突破”时刻除外）。

Answer 4

根据我的经验，我发现很多应用程序都是从一组直接的表开始，然后是一些存储过程以提供基本功能。这非常有效;它通常会产生高性能并且易于理解，它还可以减少对复杂中间层的需求。

然而，应用程序增长。看到具有数千个存储过程的大型数据驱动应用程序并不罕见。将触发器投入到混合中，你有一个应用程序，对于除了原始开发人员之外的任何人（如果他们仍在使用它），很难维护。

对于将大多数逻辑放在数据库中的应用程序，我会说一句话 - 当你有一些优秀的数据库开发人员和/或你有一个无法改变的遗留架构时，它们可以很好地工作。我之所以这么说是因为当你让他们控制架构时，ORM会从这部分应用程序开发中消除很多痛苦（如果没有，你经常需要做很多努力才能让它运行起来。）

如果我正在设计一个新的应用程序，那么我通常会选择一个由我的应用程序域决定的模式（其设计将在代码中）。我通常会让ORM处理对象和数据库之间的映射。在数据访问时，我会将存储过程视为规则的例外（在sprocs中，报告可能比试图使ORM有效地生成复杂输出更容易）。

最重要的是要记住，在设计方面没有“最佳实践”。开发人员可以在设计环境中权衡每个选项的优缺点。