3

我们应该在数据库中做多少工作？好的，我真的很困惑到底应该在数据库中完成多少“工作”，以及必须在应用程序级别完成多少工作？

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

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

如果您可以列出更多其他示例，那就太好了。

4

4 回答 4

4

这真的取决于你需要什么。
我喜欢在数据库中做我的业务逻辑，其他人强烈反对。

您可以在 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 代码放在存储过程/函数中，并尝试只在我的应用程序代码中放置简单的查询，这样我就可以编写代码来解释我在应用程序中的含义，并让数据库层完成繁重的工作。

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

于 2011-07-14T08:46:11.973 回答
0

根据我的经验，我发现许多应用程序从一组直接的表开始，然后是少量的存储过程来提供基本功能。这很好用；它通常产生高性能并且易于理解，它还减轻了对复杂中间层的任何需求。

但是，应用程序在增长。拥有数千个存储过程的大型数据驱动应用程序并不罕见。将触发器混入其中，您就有了一个应用程序，对于原始开发人员以外的任何人（如果他们仍在开发它）来说，该应用程序很难维护。

对于将大部分逻辑放在数据库中的应用程序，我会说一下——当你有一些优秀的数据库开发人员和/或你有一个无法更改的遗留模式时，它们可以很好地工作。我这么说的原因是，当您让 ORM 控制模式时，ORM 会从应用程序开发的这一部分中消除很多痛苦（如果不是，您通常需要做很多工作才能使其正常工作）。

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

但要记住的最重要的事情是，在设计方面没有“最佳实践”。开发人员可以根据您的设计来权衡每个选项的优缺点。

于 2011-07-14T09:20:08.663 回答
0

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

例如，在我以前的公司中，我们致力于计算工作时间的大型应用程序。这种应用程序的一个明显功能是跟踪员工的休假天数——员工每年有多少天，他使用了多少天，剩下多少天等等。基本上我们可以编写一些触发器和程序来自动更新这些列。因此，当员工批准他的休假天数时，他申请的天数将从他的“休假池”中取出并添加到“已使用的休假天数”中。很简单的东西，但是我们决定在应用程序级别上明确说明，男孩，很快我们很高兴我们这样做了。申请必须符合劳动法，很快就证明并非所有员工的假期都是平等计算的，有时假期可能根本不是假期，但那是无关紧要的。如果我们把这个“简单”的操作放在数据库中，我们必须对我们的数据库进行版本控制，对假期相关的逻辑进行每一次微小的更改，这将导致我们在客户支持领域直接陷入困境，因为它可以只更新应用程序无需更新数据库（当然，除了更改数据库结构的明确“突破”时刻）。

于 2011-07-14T07:34:03.570 回答
0

Data通常，从数据库中只期望“”是一个很好的做法。它取决于应用程序，以应用业务/领域逻辑并理解检索到的数据。强烈建议在应用层做以下事情：

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

但是，有时需要在数据库级别完成一些事情。

于 2011-07-14T05:23:08.660 回答