跨应用程序重用SQL存储过程

Question

我很好奇人们在许多应用程序访问的数据库中使用存储过程的方法。具体来说，您是否倾向于为每个应用程序保留不同的存储过程集，尝试使用共享集，还是进行混合？

一方面，当模型发生变化或类似情况时，重复使用SP可以减少更改，并且理想情况下维护更少。另一方面，如果应用程序的需求发生分歧，对一个应用程序的存储过程的更改可能会破坏其他应用程序。我应该注意到，在我们的环境中，每个应用程序都有自己的开发团队，它们之间的沟通很差。数据团队有更好的沟通，并且主要负责存储过程编写。

谢谢！

Answer 1

应根据您要返回的数据创建存储过程，而不是根据发出请求的应用程序创建存储过程。如果您有一个GetAllItems存储过程，它应该返回数据库中的所有项目。如果其中一个应用程序想要按类别获取所有项目，请创建GetAllItemsByCategory。没有理由根据请求数据的应用程序更改存储过程的业务规则。

Answer 2

我的经验是，多个应用程序共享SP是导致痛苦的原因。事实上，我认为拥有一个由多个应用程序直接访问的数据库并不是最好的长期架构。

我推荐并实施的模式是，只有一个应用程序应“拥有”每个数据库，并为其他应用程序提供API（服务等）以访问和修改数据。

这有几个好处：

1. 拥有的应用程序可以应用任何业务逻辑，日志记录等，以确保它保持稳定
2. 如果架构已更改，则所有接口都是已知的，并且可以进行测试以确保外部应用程序仍可正常工作

Answer 3

存储过程应该公开不会根据使用它们的应用程序而更改的业务规则。这使得规则可以存储和更新一次，而不是使用它们的每个地方，这是一场噩梦。

Answer 4

以这种方式思考：您的存储过程是关于它们下面的数据，并且不应该真正了解它们上面的应用程序。一个应用程序可能需要以另一个应用程序不能读取或更新数据的方式，因此可能会使用另一个不会使用的SP。

如果是我的应用程序/数据库/等，并且对SP进行更改以改进一个应用程序会破坏另一个应用程序，我会考虑更深层设计问题的证据。

Answer 5

我认为问题的最后一部分已经回答了。

由于沟通已经很差，开发团队之间的共享程序只会增加潜在的失败点，并可能导致团队困难。

如果我在同一个团队从事多个项目，我们将节省一些时间和共享程序，但通常我发现一点点重复（这里和那里的一些程序）有助于避免以后需要的灾难性更改/重复当应用程序开始分歧时。

LordScarlet也指出了一个关键因素，如果它是通用的，没有业务逻辑共享它不应该是一个问题。

Answer 6

每当我们拥有多个应用程序共有的存储过程时，我们就会为这些过程（以及视图和表格等）创建一个数据库。那个数据库（我们命名为“base”）将由一个开发人员（或团队）负责（维护和测试）。

如果一个不同的团队需要新功能，他们可以编写它，而基础开发人员可以在基础DB中实现它，或者建议一种更简单的方法。

Answer 7

这一切都取决于你的抽象策略。存储过程是否被视为离散的抽象点，或者它们只被视为调用它们的应用程序的另一部分。

答案将告诉您如何管理它们。如果它们是离散的抽象，它们可以共享，就像您需要新功能一样，您将添加新的过程。如果他们是调用它们的应用程序的一部分，则不应共享它们。

Answer 8

我们尝试尽可能使用单个共享存储过程，但我们也遇到了您描述的情况。我们通过向存储过程（ApplicationName_StoredProcName）添加应用程序前缀来处理它。

这些存储过程通常会调用集中式或“主”存储过程，但这种方法可以为将来的应用程序特定更改留出空间。

Answer 9

我不认为在多个应用程序之间共享Sprocs是有道理的。

我可以看到在相关应用程序中共享数据库的情况，但可能这些应用程序在很大程度上是分开的，因为它们彼此之间的处理方式截然不同。

使用相同的体系结构可以跨应用程序工作，但想象一下尝试在多个应用程序中使用相同的业务逻辑层。 “可是等等！”你说，“这很愚蠢......如果我使用相同的BLL，为什么我会有一个单独的应用程序？他们做同样的事情！”

QED。

Answer 10

理想情况下，使用一个proc而不是多个版本。如果您需要每个客户的版本，请调查每个客户1分贝的想法，而不是所有客户的1分贝。这也允许在不同的服务器上进行一些有趣的db分段（将较大/较重的使用分配给较大的服务器，而较小的分配可以共享硬件）

Answer 11

如果您希望能够共享SQL代码，请尝试构建抽象函数库。通过这种方式，您可以重用一些执行通用事务的代码，并为每个应用程序保持业务逻辑。对于视图也可以这样做 - 它们可以保持非常通用并且对许多应用程序有用。

您可能会发现，随着常规存储过程的使用并不多。

这就是说我们曾经实施过一个项目，该项目使用设计非常糟糕的遗留数据库。我们实现了一组存储过程，使信息检索变得容易。当来自其他团队的其他人想要使用相同的信息时，我们重构了我们的存储过程以使它们更通用，添加了额外的评论和文档层，并允许其他人使用我们的过程。该解决方案效果很好。

Answer 12

许多存储过程与应用程序无关，但可能有一些与应用程序有关。例如，CRUD（创建，选择，更新，删除）存储过程可以跨应用程序。特别是你可以抛出审计逻辑（有时在触发器中完成，但是触发器的复杂程度有限）。如果您的软件商店中有某种类型的标准体系结构，则中间层可能需要存储过程来创建/选择/更新/删除数据库，无论应用程序在何种情况下共享该过程。

同时，可能有一些查看数据的有用方法，即GetProductsSoldBySalesPerson等，它们也将独立于应用程序。对于某些字段（如部门，地址等），您可能有一堆查找表，因此可能会有一个过程来返回包含所有文本字段的表视图。即代替SalesPersonID，SaleDate，CustomerID，DepartmentID，CustomerAddressID，该过程返回一个视图SalesPersonName，SaleDate，CustomerName，DepartmentName，CustomerAddress。这也可以跨应用程序使用。客户关系系统需要客户名称/地址/其他属性以及计费系统。因此，在一个查询中完成所有连接并获得所有客户信息的内容可能会跨应用程序使用。不可否认，创建查看数据的方法是视图的领域，但通常人们使用存储过程来执行此操作。

所以基本上，当从表中删除时，您需要从3或4个其他表中删除以确保数据完整性。触发器的逻辑是否过于复杂？然后，所有应用程序用于执行删除的存储过程可能很重要。对于需要在创建时需要完成的事情也是如此。如果总是有常见的连接，那么让一个存储过程进行所有连接可能是有意义的。然后，如果以后更改表格，您可以保持程序相同，只需更改那里的逻辑。

Answer 13

跨多个应用程序共享数据模式的概念非常困难。由于性能原因，您的架构总是会受到损害：非规范化，它会创建索引。如果您可以将一行的大小减半，则可以将每页的行数加倍，并且可能会将扫描表所需的时间减半。但是，如果您只在主表上包含“常用”功能，并且只保留对不同（但相关）表中特定应用程序感兴趣的数据，则必须在任何地方加入以回到“单表”的想法。

支持不同应用程序的更多索引将导致从每个表中插入，更新和删除数据的时间不断增加。

数据库服务器通常也会成为瓶颈，因为数据库无法进行负载平衡。您可以跨多个服务器对数据进行分区，但这也非常复杂。

最后，所需的协调程度通常很大，毫无疑问，不同部门之间的争斗优先于其要求，新的发展将陷入困境。

通常，“每个应用程序的隔离数据孤岛”模型效果更好。我们所做的一切 - 我在合同软件公司工作 - 都是基于从我们应用程序自己的数据库导入数据和将数据导出到其他系统。

在数据仓库/决策支持系统中可能更容易;我通常在事务性能至关重要的OLTP系统上工作。