我们应该在数据库中做多少工作?好吧，我真的很困惑到底有多少"工作"应该在数据库中完成，有多少工作必须在应用程序级别完成?
我的意思是，我不是在谈论明显的东西，比如我们应该在应用程序级别而不是数据库级别将字符串转换为SHA2哈希。
而是更模糊的东西，包括但不限于"我们应该检索4列的数据并在应用程序级别进行大写/连接，还是我们应该在数据库级别执行这些内容并将计算结果发送到应用程序级别?"
如果你能列举更多的例子，那就太好了。
这取决于你需要什么。
我喜欢在数据库中做我的业务逻辑，其他人则坚决反对。
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
在触发器和存储过程中执行业务逻辑的原因
请注意，我不是在谈论将数据库结构向业务逻辑倾斜，而是在谈论将业务逻辑放在触发器和存储过程中。
- 它集中了你的逻辑，数据库是一个中心位置，一切都必须通过它。如果你的应用程序中有多个插入/更新/删除点(或者你有多个应用程序)，你需要多次检查，如果你在数据库中做，你只需要在一个地方做检查。
- 它简化了应用程序例如，您可以添加一个成员，数据库将确定该成员是否已知并采取适当的行动。
- 它从应用程序中隐藏了数据库的内部，如果你在应用程序中完成所有的逻辑，你将需要对应用程序中的数据库有复杂的了解。如果你使用数据库代码(触发器/进程)来隐藏它，你不需要知道应用程序中的每个数据库细节。
- 这使得它更容易重构你的数据库如果你有你的数据库的逻辑，你可以只是改变一个表布局，用黑洞表取代旧表，把一个触发器，让触发器做更新到新的表，你的应用程序甚至不需要知道数据库已经改变，这允许遗留的应用程序保持不变的工作，而新的应用程序可以使用改进的数据库布局。
- SQL
- SQL
- 我不喜欢在我的应用程序中使用(大量和/或复杂)SQL代码，我喜欢将SQL代码放在存储过程/函数中，并尝试在我的应用程序代码中只放置简单的查询，这样我就可以编写代码来解释我在应用程序中的意思，并让数据库层做繁重的工作。
有些人强烈反对这种方法，但这种方法对我来说很有效，并且大大简化了我的应用程序的调试和维护。
一般来说，只期望从数据库中得到" Data "是一个很好的做法。这取决于应用程序，应用业务/领域逻辑并理解检索到的数据。强烈建议在应用层做以下事情:
1)格式化日期2)应用数学函数，如插值/外推等3)动态排序(基于列)
然而，有时情况保证在数据库级别做的事情很少。
在我看来，应用程序应该使用数据，数据库应该提供数据，这应该是明确的关注点分离。因此，数据库根据所请求的条件对记录进行排序，排序和过滤，但这取决于应用程序对这些记录应用一些业务逻辑并将它们"转换"为对用户有意义的内容。
例如，在我以前的公司，我们做过一个计算工作时间的大应用程序。这类应用程序中一个明显的功能是跟踪员工的假期——员工每年有多少天，用了多少天，还剩多少天，等等。基本上，我们可以编写一些触发器和过程来自动更新这些列。因此，当员工有假期时，他申请的天数将从他的"假期池"中取出并添加到"已使用的假期"中。非常简单的东西，但我们决定在应用程序层面明确它，很快我们就很高兴我们这样做了。申请必须符合劳动法，但很快就发现，并不是所有员工的假期都是平等计算的，有时假期可能根本不是假期，但这不是重点。如果我们把这种"简单"的操作放在数据库中，我们就必须对数据库的版本进行修改，每做一点与假期相关的逻辑变化，这将导致我们直接在客户支持领域陷入困境，因为我们有可能只更新应用程序，而不需要更新数据库(当然，数据库结构发生改变的明显"突破性"时刻除外)。
根据我的经验，我发现许多应用程序从一组直接的表开始，然后使用少量存储过程来提供基本功能。这非常有效;它通常产生高性能并且易于理解，它还减少了对复杂中间层的任何需求。
然而，应用程序在增长。拥有数千个存储过程的大型数据驱动应用程序并不罕见。把触发器加入其中，你就有了一个除了原始开发者(如果他们还在开发)之外的任何人都很难维护的应用程序。
我将用一个词来形容那些将大部分逻辑放在数据库中的应用程序——当你有一些优秀的数据库开发人员和/或你有一个无法更改的遗留模式时，它们可以很好地工作。我这样说的原因是，当您让orm控制模式时，orm可以减轻应用程序开发的这一部分的痛苦(如果不这样做，您通常需要做大量的调整才能使其工作)。
如果我正在设计一个新的应用程序，那么我通常会选择一个由我的应用程序领域决定的模式(其设计将在代码中进行)。我通常会让ORM处理对象和数据库之间的映射。当涉及到数据访问时，我会将存储过程视为规则的例外(在过程中报告比试图诱使ORM有效地产生复杂的输出要容易得多)。
但最重要的是要记住，当涉及到设计时，没有"最佳实践"。作为开发人员，你应该在你的设计环境中权衡每个选项的利弊。