“从没有做过代码就无法使SQL Server为您做的更好”-这是设计不良的秘诀吗？

我在很多地方都听到过这个想法。或多或少地认识到，一旦尝试仅使用SQL解决问题就超过了一定程度的复杂性，那么您确实应该在代码中进行处理。

这个想法背后的逻辑是，在大多数情况下，数据库引擎在寻找完成任务的最有效方式方面将比在代码中做得更好。尤其是涉及将结果取决于对数据执行的操作之类的事情时。可以说，对于现代引擎而言，有效地JIT'ing +缓存查询的编译版本在表面上是有意义的。

问题是，以这种方式利用数据库引擎是否本质上是不良的设计实践（以及为什么）。当所有逻辑都存在于数据库中并且您只是通过ORM命中它时，这些界限会进一步模糊。

用外行的话来说：

这些是SQL要做的事情，无论是否相信，我都在代码中看到过：

• 联接 -以代码方式需要复杂的数组操作
• 过滤数据（在哪里）-以代码方式需要大量插入和删除列表中的项目
• 选择列 -以代码方式需要大量列表或数组操作
• 聚合函数 -逐个代码地需要数组来保存值和复杂的切换条件
• 外键完整性 -以代码方式，插入前需要查询，并假设没有人会在应用程序外部使用数据
• 主键完整性 -以代码方式，插入前需要查询，并假设没有人会在应用程序外部使用数据

代替依赖SQL或RDBMS 来执行这些操作会导致编写大量无附加值的代码，这意味着需要调试和维护更多的代码。并且危险地假设只能通过应用程序访问数据库。

我将其改写为“从不做任何代码，SQL Server可以为您做的很好 ”。

诸如字符串操作，正则表达式之类的东西都可以在SQL Server中使用（除非SQL CLR）。

上面倾向于谈论诸如连接，设置操作和查询之类的事情。其背后的目的是将大部分繁重的工作委托给SQL Server（在它擅长的事情上），并尽可能减少IO的数量（因此，让SQL执行联接并使用WHERE子句过滤掉，返回很多较小的数据集）。

在代码中你可以得到SQL服务器做决不做好为你（重点是我的）

答案的关键是您需要寻找SQL为您做得好，而不是简单地做某事。SQL是一种非常强大的语言。结合内置功能，它可以做很多事情。但是，您可以在SQL中执行某些操作这一事实不应成为在SQL中实际执行操作的借口。

我做出决定的具体标准是查看您获得的数据量和往返次数：是否可以通过将任务运送到服务器来减少数据量，而又不增加往返次数。跳闸，则任务属于服务器；如果数据量保持不变或增加而往返次数没有同时减少，则该任务属于您的代码。

考虑以下示例：

• 您存储出生日期，并且需要计算一组用户的年龄。您可以让SQL Server进行减法，也可以在代码中进行。往返次数保持不变，发送回给您的数据量也增加。因此，基于代码的解决方案必胜
• 您存储一个出生日期，并且需要查找年龄在20到30岁之间的用户。您可以将所有用户重新加载到客户端，进行减法以查找年龄，然后进行过滤，但是将逻辑传递给SQL Server将减少数据量，而无需进行额外的往返；因此，基于SQL的解决方案将获胜。

简而言之，应该正确地说：“永远不要在代码库中执行数据库特定的操作 ”，因为在数据库中可以更好地解决它们。

看一下设置基本操作的示例。如您所知，RDBMS是为处理常见的数据存储和操作而构建的。

另外，数据库的项目选择也起着重要的作用。拥有RDBMS（MS SQL，Oracle等）不同于RavenDB等NoSQL数据库。

通常，与应用程序相比，您的数据库具有更多可使用的信息，并且可以更有效地执行常见数据操作。例如，您的数据库维护索引，而您的应用程序则必须动态索引搜索结果。因此，在所有其他条件相同的情况下，可以通过将工作推送到数据库而不是应用程序来减少总体工作量。

但是随着产品扩展，扩展应用程序通常比扩展数据库变得容易。在大型安装中，经常看到应用程序服务器的数量超过数据库服务器10到1或更多倍。添加更多应用服务器通常是将现有服务器克隆到新硬件上的简单问题。另一方面，在大多数情况下，添加新的数据库服务器要困难得多。

因此，这时的口头禅成了保护数据库。事实证明，通过缓存数据库结果memcached或在应用程序侧日志中对更新进行排队，或者通过一次获取数据并计算应用程序中的统计信息，您可以极大地减少数据库的工作量，从而不必再依赖于更复杂，更脆弱的数据库集群配置。

我认为，不使用数据库来完成它的设计将是一个糟糕的设计。我从来没有见过任何数据库在数据良好的数据库之外强制实施规则的数据库。我查看了数百个数据库。

所以必须在数据库中完成的事情：

• 审核（仅应用程序审核不会跟踪数据库的所有更改，因此毫无价值）。

• 数据敏感度约束包括默认值，外键约束和必须始终应用于所有数据的规则。并非总是可以通过应用程序更改或插入所有数据，尤其是对于大型数据集，它具有一次性的数据修复功能，一次无法记录一个记录（请更新这100,000条记录，这些记录在被标记为状态1时应予以标记）归因于应用程序代码错误为2或请更新所有从客户端A到客户端B的记录，因为公司B购买了公司A）和数据导入以及其他可能涉及同一数据库的应用程序。

• JOINS和where子句过滤（以减少通过网络发送的记录数）

“过早的优化是计算机编程中所有邪恶的根源（无论如何，绝大部分）”- Donald Knuth

数据库就是那个。应用程序的数据层。它的工作是为您的应用程序提供所需的数据，并存储提供给它的数据。您的应用程序是放置实际可用于数据的代码的地方。显示，验证等。

而在标题行中的情绪是令人钦佩的，并精确到一个点（滤波的基本事实，突出，分组等应在绝大多数情况下留给DB）的“井”可能是一个定义订购。SQL Server可以执行的高性能任务很多，但是您可以演示的任务SQL Server以隔离，可重复的方式正确运行的知识很少。SQL Management Studio是一个很棒的数据库IDE（特别是考虑到我曾使用过的其他选项，例如TOAD），但是它有其局限性，首先是要使用它做的几乎所有事情（或在其中执行的任何过程代码）根据定义，下面的DB）是“副作用”（更改状态位于进程的内存空间范围之外）。此外，SQL Server中的过程代码只是最新的功能，可以使用最新的IDE和工具来衡量托管代码使用覆盖率度量和路径分析的方式（因此，您可以证明测试X遇到此特定if语句） ，Y和Z，而测试X旨在使条件成立并执行一半，而Y和Z执行“其他” 。相应地，假定您有一个测试，该测试可以将数据库设置为特定的启动状态，通过某些操作执行数据库过程代码，并声明期望的结果。

与大多数数据访问层提供的解决方案相比，所有这些都更加困难和复杂。假设数据层（以及DAL）知道如何在给出正确输入的情况下完成工作，然后测试您的代码是否提供正确输入。通过将诸如SP和触发器之类的过程代码保留在DB之外，而在应用程序代码中执行这些类型的操作，可以轻松实现所述应用程序代码。

人们似乎没有意识到的一件事是，不管对代码质量的影响如何，在SQL Server上进行所有处理不一定都很好。

例如，如果您需要获取一些数据，然后从该数据中计算出一些数据，然后将该数据存储在数据库中。有两种选择：

• 将数据获取到您的应用程序中，在您的应用程序中进行计算，然后将数据发送回数据库
• 设计一个存储过程或类似的过程来获取数据，在其中进行计算，然后通过一次对SQL Server的调用将所有数据存储起来。

您可能会认为第二个解决方案始终是最快的，但这绝对不是事实。即使SQL不适合解决该问题（例如正则表达式和字符串操作），我也忽略了。假设您有SQL CLR或类似的东西甚至在数据库中拥有强大的语言。如果需要1秒钟来回往返并获取数据，然后花1秒钟来存储数据，然后需要10秒钟来对它进行计算。如果您在数据库中全部都做错了，那就错了。

当然，您要剃掉2秒钟。但是，您是将100％的（至少）一个CPU内核浪费了10秒（还是至少10秒钟）还是在Web服务器上浪费了该时间？

Web服务器易于扩展，而数据库则非常昂贵，尤其是SQL数据库。大多数情况下，Web服务器也是“无状态”的，可以随时添加和删除，而无需对负载平衡器进行任何其他配置。

因此，不仅要考虑将操作减少2秒钟，还要考虑可伸缩性。当可以使用便宜得多的Web服务器资源且对性能的影响较小时，为什么要浪费数据库服务器资源之类的昂贵资源

我喜欢看它，因为SQL应该只处理数据本身。决定查询外观的业务规则可以在代码中发生。信息的正则表达式或验证应通过代码完成。应该保留SQL以便仅连接表，查询数据，插入干净数据等。

传递给SQL的应该是干净的数据，SQL真正不需要知道的只是存储，更新，删除或检索某些信息。我已经看到太多的开发人员希望将其业务逻辑和编码用SQL编写，因为他们将数据视为业务。将逻辑与数据脱钩，您会发现代码变得更简洁，更易于管理。

不过只有我的$ 0.02。

通常，我同意代码应控制业务逻辑，而数据库应为无逻辑哈希。但是这里有一些要点：

主，外键和必需（非null）约束可以由代码强制实施。约束是业务逻辑。是否应该将它们排除在数据库之外，因为它们重复了可以执行的代码？

您无法控制的其他各方是否接触数据库？如果是这样，则在数据附近强制执行约束是很好的。可以将访问限制为实现逻辑的Web服务，但这假定您在“第一”并且有权在其他各方上强制使用该服务。

您的ORM是否为每个对象执行单独的插入/更新？如果是，那么在批处理大数据集时将遇到严重的性能问题。设置操作是必经之路。ORM在准确建模所有可能要执行操作的联接集时会遇到麻烦。

您是否将“层”视为服务器的物理拆分还是逻辑拆分？从理论上讲，任何服务器上运行的逻辑都可能仍属于其逻辑层。您可以通过编译到不同的DLL中来组织拆分，而不是专门拆分服务器。这可以显着增加响应时间（但会牺牲吞吐量），同时保持关注点分离。拆分的DLL以后可以在没有新版本的情况下移动到其他服务器，以增加吞吐量（以响应时间为代价）。

习惯用法更多地与保持业务规则，与数据以及关系（数据，结构和关系）有关。它不是解决所有问题的一站式服务，但有助于避免手动操作如果在数据库级别可用，则维护记录计数器，手动维护关系完整性等。因此，如果其他人出现并扩展程序或编写与数据库交互的另一个程序，他们将不必从以前的代码中找出如何维护数据库完整性的方法。当其他人想要编写新程序以与同一数据库进行交互时，手动维护记录计数器的情况尤为重要。即使新创建的程序具有正确的计数器代码，原始程序和同时运行的新程序可能会破坏它。甚至还有代码可以检索记录并在写入新的或更新的记录之前（通过代码或作为单独的查询）检查条件，如果可能的话，通常可以在insert或update语句中实现。数据损坏可能再次导致。数据库引擎保证原子性；确保带有条件的更新或插入查询仅影响满足条件的记录，并且没有外部查询可以在更新进行到一半时更改数据。在许多其他情况下，最好使用数据库引擎来使用代码。这全都与数据完整性有关，而与性能无关。甚至可以在其中编写代码来检索记录并检查条件，然后再编写新的或更新的记录（以代码或作为单独的查询），如果可能，通常可以在insert或update语句中实现。数据损坏可能再次导致。数据库引擎保证原子性；确保带有条件的更新或插入查询仅影响满足条件的记录，并且没有外部查询可以在更新进行到一半时更改数据。在许多其他情况下，最好使用数据库引擎来使用代码。这全都与数据完整性有关，而与性能无关。甚至可以在其中编写代码来检索记录并检查条件，然后再编写新的或更新的记录（以代码或作为单独的查询），如果可能，通常可以在insert或update语句中实现。数据损坏可能再次导致。数据库引擎保证原子性；确保带有条件的更新或插入查询仅影响满足条件的记录，并且没有外部查询可以在更新进行到一半时更改数据。在许多其他情况下，最好使用数据库引擎来使用代码。这全都与数据完整性有关，与性能无关。数据库引擎保证原子性；确保带有条件的更新或插入查询仅影响满足条件的记录，并且没有外部查询可以在更新进行到一半时更改数据。在许多其他情况下，最好使用数据库引擎来使用代码。这全都与数据完整性有关，与性能无关。数据库引擎保证原子性；确保带有条件的更新或插入查询仅影响满足条件的记录，并且没有外部查询可以在更新进行到一半时更改数据。在许多其他情况下，最好使用数据库引擎来使用代码。这全都与数据完整性有关，与性能无关。

因此，这实际上是一个很好的设计习惯或经验法则。在数据损坏的系统中，没有任何性能可以提供帮助。

如前所述，目标是在数据库中尽可能少地收发数据，因为往返时间非常昂贵。一遍又一遍地发送SQL语句是浪费时间，尤其是在更复杂的查询中。

使用数据库中的存储过程可以使开发人员像API一样与数据库进行交互，而不必担心背面的复杂架构。由于仅发送名称和一些参数，因此它也减少了发送到服务器的数据。在这种情况下，大多数商务逻辑仍可以在代码中，但不能以SQL形式。该代码实质上将准备从数据库发送或请求的内容。

有几件事要记住：

• 关系数据库应通过外键确保引用完整性
• 扩展一个数据库可能既困难又昂贵。只需添加更多Web服务器，即可轻松扩展Web服务器。尝试增加SQL Server功能会很有趣。
• 使用C＃和LINQ，您可以通过代码进行“联接”之类的事情，因此在很多情况下都可以做到两全其美

“过早的优化是万恶之源”-Donald Knuth

使用最适合该工作的工具。为了数据完整性，通常是数据库。对于高级业务规则，这是基于规则的系统，例如JBoss Drools。对于数据可视化，这将是一个报告框架。等等

如果您有任何性能问题，则应随后查看是否可以缓存任何数据，或者是否可以更快地实现数据库中的实现。通常，购买额外服务器或额外云功能的成本将远低于增加的维护成本和额外错误的影响。