小方法 - 小sprocs

Question

鲍勃叔叔建议使用小方法。存储过程是否具有理想的大小？或者它们可以长时间运行100和100的线路？

也有人有任何关于在哪里放置业务逻辑的说法。如果位于存储过程中，则数据库将用作数据处理层。

如果你读过Adam Machanic，他偏向于数据库，这是否意味着只有sproc的作者能理解的长存储过程，让维护人员处理这些混乱？

我猜不过有两个相互关联的问题。

提前感谢您回答模糊问题。

Answer 1

存储过程与常规功能没有什么不同。无论如何，它们应该具有可管理的大小。我偏向于从存储过程中保留业务逻辑，但合理的人可能不同意。

Answer 2

我认为现在的存储过程绝不应该在整个系统上用作数据库的唯一访问方法。这是一种过时的体系结构，从长远来看，它提供的维护问题要多于好处。 现在有更好的方法来处理每个数据访问要求。 存储过程的最佳用途是，对于某些极少数情况，当您需要一个定义良好且功能独特的函数来检索数据时，您知道它将被更多应用程序以相同的方式使用。在这种情况下，存储过程将允许您进行DRY。 此外，在某些情况下，处理安全性的数据库管理员需要以允许仅访问SP的精细方式保护数据的某些部分（例如信用卡表），这是一个不错的选择。

除了这些情况之外，尽可能避免存储过程，并且只使用具有继承，编译器检查，重构工具，查询中的枚举而不是魔术字符串的代码，源代码控制，更容易部署等等所有优点。尽可能避免SP的好处列表现在太长了，无法通过。

但是如果由于某种原因你决定使用存储过程，那么你也可以将业务逻辑放在那里，因为这样一个层如此接近数据而不允许它包含业务逻辑只会使你的项目更加复杂，你会没有收获使用SP的极少数积极点。

Answer 3

当我考虑SP的代码时，我会尽可能地向SP提出相同的建议。

我认为业务逻辑属于代码库的一层而不是SP。对我而言，如果SP保持业务逻辑，他们对他们应该做的事情了解得太多。我认为SP主要用于检索数据和/或存储数据时的任务。如果业务逻辑已经应用于代码链/代码中，那么只有在满足业务逻辑时才会调用SP。

我怀疑Adam Machanic或大多数人会主张那些难以理解和维护的长SP是一件好事。