sql - 你能有太多的存储过程吗？

Question

是否存在存储过程过多之类的东西？

我知道你可以拥有的数量是没有限制的，但这是否有任何性能或架构原因不创建数百、数千？

score 7 · Accepted Answer

对我来说，成百上千个存储过程的最大限制是可维护性。即使这不是直接的性能影响，它也应该是一个考虑因素。这是一个架构的观点，你不仅要为应用程序的初始开发做计划，还要为未来的更改和维护做计划。

话虽如此，您应该设计/创建应用程序所需的数量。尽管使用 Hibernate、NHibernate、.NET LINQ，但我会尝试在代码中保留尽可能多的存储过程逻辑，并且仅在速度是一个因素时才将其放入数据库中。

score 7 · Accepted Answer

7

是的你可以。

如果你有超过零，你有太多

于 2008-09-25T20:45:53.437 回答

score 4 · Accepted Answer

我的商业 SQL Server 2005 产品中只有不到 200 个，在接下来的几天中，对于一些新报告，它可能会再增加大约 10-20 个。

在可能的情况下，我会编写“子例程”存储过程，因此每当我发现自己将 3 或 4 个相同的语句放在多个存储过程中时，如果您明白我的意思，是时候将这几个语句变成子例程了。

我不倾向于使用 sprocs 来执行所有业务逻辑，我只是更喜欢让 sprocs 做任何可以被视为“事务性”的事情 - 所以我的客户端代码（在 Delphi 中，但无论如何）可能会做奇怪的插入或更新本身，一旦某些东西需要“一次”更新或插入一些东西，就该使用sproc了。

我有一个简单粗暴的命名约定来帮助提高可读性（和维护！）

该产品的代号是“Rachel”，所以我们有

RP_whatever - 这些是更新/插入数据的通用存储过程，
              - 或返回小结果集

RXP_whatever - 这些是作为“函数”服务的子程序存储过程
              - 或 RP_ 类型 procs 的工人

REP_whatever - 这些是几乎充当美化视图的存储过程
              - 他们不改变数据，他们返回潜在的复杂结果集
              - 用于报告等

XX_whatever - 这些是内部测试/开发/维护存储过程
              - 客户端应用程序（或本地 dba）通常不会使用

命名是任意的，只是为了帮助区分 SQL Server 使用的 sp_ 前缀。

我想如果我发现数据库中有 400-500 个 sproc，我可能会担心，但只要您有一个系统来识别每个 sproc 负责的活动类型，几百个就不是问题。我宁愿在几百个存储过程中追踪架构更改（SQL Server 工具可以帮助您找到依赖项等），而不是尝试在我的高级编程语言中追踪架构更改。

score 4 · Accepted Answer

我想这里更深层次的问题是——所有这些代码还应该去哪里？视图可用于通过标准 SQL 方便地访问数据。更强大的应用程序语言和库可用于生成 SQL。存储过程往往会掩盖数据的性质，并为系统引入不必要的抽象层、复杂性和维护层。

鉴于对象关系映射工具生成基本 SQL 的能力，任何过度依赖存储过程的系统的开发效率都会降低。使用 ORM，只需编写更少的代码。

score 3 · Accepted Answer

您的意思是除了在对数据库进行更改时必须维护所有这些之外吗？这就是我的重要原因。最好有更少的可以处理多种场景的场景，而不是数百个只能处理一种场景的场景。

score 3 · Accepted Answer

我只想提一下，在所有这些事情中，维护成为一个问题。谁知道它们都是什么以及它们的用途是什么？如果它们只是遗留系统的产物，没有人能回忆起它们的用途，但又害怕惹麻烦，那么几年后会发生什么？

我认为主要的问题是不可能，但应该这样做。无论如何，这只是一个想法。

score 3 · Accepted Answer

地狱是的，你可以有太多。几年前我在一个系统上工作过，它有大约 10,000 个 procs。这太疯狂了。编写系统的人并不真正知道如何编程，但他们确实知道如何纠正结构不良的 procs，因此他们将几乎所有应用程序逻辑都放在了 procs 中。一些 procs 运行了数千行。管理混乱是一场噩梦。

太多（我无法在沙子中为您画出一条特定的线）可能表明设计不佳。此外，正如其他人所指出的，有更好的方法来实现粒度数据库接口，而无需求助于大量的 proc。

score 2 · Accepted Answer

我的问题是，如果您谈论成百上千的存储过程，为什么不使用某种中间件平台？

称我为老式的，但我认为数据库应该只保存数据，而程序应该是制定业务逻辑决策的程序。

score 2 · Accepted Answer

在 Oracle 数据库中，您可以使用 Packages 将相关过程组合在一起。

其中一些和您的命名空间将被释放。

score 2 · Accepted Answer

任何特定的事情太多可能意味着你做错了。配置文件太多，屏幕上的按钮太多...

不能代表其他 RDBMS，但使用 PL/SQL 的 Oracle 应用程序应该在逻辑上将过程和函数捆绑到包中，以防止级联失效并更好地管理代码。

score 2 · Accepted Answer

对我来说，使用大量存储过程似乎会引导您走向与 PHP API 等效的东西。数以千计的可能彼此无关的全局函数全部组合在一起。将它们联系起来的唯一方法是有一些命名约定，在每个函数前面加上一个模块名称，类似于 PHP 中的 mysql_ 函数。我认为这很难维护，也很难保持一切一致。我认为存储过程适用于真正需要在服务器上发生的事情。一个简单的选择查询的存储过程，甚至是一个带有连接的选择查询可能会走得很远。仅在实际需要在数据库服务器上处理高级逻辑的情况下使用存储过程。

score 1 · Accepted Answer

正如其他人所说，这实际上归结为管理方面。过了一会儿，它变成了大海捞针。当命名标准不佳时，情况更是如此......

score 1 · Accepted Answer

不，不是我知道的。但是，您应该为它们制定一个良好的命名约定。例如，以 usp_ 开头是很多人喜欢做的事情（比以 sp_ 开头要快）。

也许你的报告存储过程应该是usp_reporting_，你的业务对象应该是usp_bussiness_等等。只要你可以管理它们，拥有很多它们应该没有问题。

如果它们变得太大，您可能希望将数据库拆分为多个数据库。这可能更具逻辑意义，并且可以帮助解决数据库大小等问题。

score 1 · Accepted Answer

如果你有很多存储过程，你会发现你把自己绑在一个数据库上——其中一些可能不容易转移。

将自己绑定到一个数据库并不是好的设计。

此外，如果您在数据库和业务层中有业务逻辑，那么维护就会成为问题。

score 1 · Accepted Answer

是的，你可以有太多的存储过程。

命名约定可以真正帮助解决这个问题。例如，如果您有一个命名约定，其中始终有表名和 InsUpd 或 Get，那么在需要时很容易找到正确的存储过程。如果您没有某种标准的命名约定，那么很容易想出两个（或更多）几乎完全相同的过程。

如果没有标准化的命名约定，很容易找到以下几个... usp_GetCustomersOrder、CustomerOrderGet_sp、GetOrdersByCustomer_sp、spOrderDetailFetch、GetCustOrderInfo 等。

当您拥有大量存储过程时，另一件开始发生的事情是您将拥有一些从未使用过的存储过程和一些很少使用的存储过程......如果您没有某种方法来跟踪存储过程的使用情况，那么您要么会导致很多未使用的程序......或者更糟糕的是，摆脱一个你认为从未使用过的程序，然后发现它每年或每季度只使用一次。:(

杰夫

score 1 · Accepted Answer

当你有健全的命名约定、最新的文档和足够的单元测试来保持它们的组织时，就不会了。

score 1 · Accepted Answer

我的第一个大项目是使用抽象数据库的对象关系映射器开发的，所以我们做了所有面向对象的事情，更容易维护和修复错误，而且由于所有数据访问和业务逻辑都是 C# 代码，因此进行更改特别容易，然而，当涉及到做复杂的事情时，系统感觉很慢，所以我们不得不解决这些事情或重新设计项目，尤其是当 ORM 必须在数据库中进行复杂的连接时。

我现在在一家不同的公司工作，该公司的座右铭是“我们的应用程序只是数据库的前端”，它有其优点和缺点。我们有非常快的应用程序，因为所有的数据操作都是在存储过程上完成的，这主要使用 SQL Server 2005，但是，当涉及到对软件进行更改或修复时，它就更难了，因为你必须同时更改两者， C# 代码和 SQL 存储过程，所以它就像工作两次，与我使用 ORM 时相反，你在 sql、Management Studio 和其他工具中没有重构或强类型对象有很大帮助，但通常你会花更多时间这样做.

所以我想说，根据项目的需要，如果您不打算保留真正复杂的业务数据，那么您甚至可以完全避免使用存储过程并使用使开发人员生活更轻松的 ORM。如果您关心性能并且需要节省所有资源而不是使用存储过程，当然，数量取决于您设计的体系结构，因此例如，如果您总是有用于 CRUD 操作的存储过程，您将需要一个对于插入，一个用于更新，一个用于删除，一个用于选择，一个用于列出，因为这些是最常见的操作，如果您有 100 个业务对象，将这 4 个乘以，您将得到 400 个存储过程，仅用于管理最基本的操作对您的对象进行的操作，是的，它们可能太多了。

score 0 · Accepted Answer

我认为只要您将它们命名为 uspXXX 而不是 spXXX，则按名称查找将是直接的，因此没有缺点-尽管您可能想知道如果您有数千个 proc 来概括这些 proc...

score -1 · Accepted Answer

你必须把所有的代码放在某个地方。
如果您将拥有存储过程（我个人很喜欢它们，但很多人不喜欢），那么您不妨尽可能多地使用它们。至少所有的数据库逻辑都在一个地方。缺点是一个充满存储过程的存储桶通常没有太多结构。

你的来电！:)

sql - 你能有太多的存储过程吗？

19 回答 19

Related

Reference