为了使代码更易于维护（即更轻松地更改业务规则而不重新编译代码），在存储过程中放置代码的理由和反对是什么？
所有其他条件相同的是什么使存储过程更好/更差的维护？
答案 0 :(得分：22)
由于多种原因，存储过程是一种不好的做法。
其中一个最重要的问题是分离关注点。使用存储过程，您可以在数据层中使用业务逻辑，而不是在其所属的服务层中。这样做的一个结果是，您现在只能使用一种语言和一种语言来实现业务逻辑。随着新技术的出现，你没有良好的迁移路径。
避免存储过程的另一个可靠理由是存储过程会在您与数据库供应商之间建立强大的联系。将更改为不同的数据库供应商将非常困难，而在服务层中拥有业务逻辑将允许您非常轻松地交换数据库。因此，存储过程为数据库供应商提供了很大的好处，而不是为您提供。
接下来，可扩展性。在中间层创建服务并在集群中分发服务非常简单。你打算用存储过程怎么做？我认为将存储过程集中在甚至八台机器上是非常困难的。
接下来，与其他系统集成。如果您的系统从数据库中提取数据，依赖存储过程以及来自其他系统的其他数据，那么该逻辑几乎肯定必须位于服务层中。如果您的某些业务逻辑位于服务层中，而某些业务逻辑位于业务层中，那么您将面临一些维护麻烦。
答案 1 :(得分：11)
这可能取决于您的系统。对我们来说，Stored Procs几乎全部使用。我们只有一个网站，因此在存储过程中使用SQL语句会使我们的DBA更容易调整查询并重新创建导致问题的性能。
答案 2 :(得分：11)
想想替代方案......
然后考虑您的要求和环境......
您的开发人员是否熟悉您的数据库管理工具，或者您是否有更多的数据库程序员和管理员处理数据库管理工具？
您是否需要频繁更改数据库架构？
安全性怎么样？您是否一直需要安全性到数据库用户级别？在代码或db中管理安全性会更容易吗？
您的开发人员是否可以通过ORM提高工作效率，而不必为自己编写DAL，或者您是否希望以自定义方式向DAL添加ORM无法提供的复杂性？
等...
根据他们工作的系统和环境可能与您自己的系统和环境大不相同，人们会对procs是否更容易维护有不同的看法。您应该做的不仅仅是想知道它们是否更容易维护，而是要弄清楚它们是否满足您的需求。这是一个非常好的问题，但也许可以编辑你的帖子并解释一下你的环境。你可能会得到更有针对性的建议。
答案 3 :(得分：9)
存储过程提供了许多优于在应用程序中保留查询的优点，并且已经提到了许多优点。
存储过程充当应用程序和数据之间的抽象层，抽象层很少是坏事。
如果您具有级联数据库操作，则可以实现一定程度的重用。例如，Delete_Employee过程可以在事务中调用Delete_Address过程，并使用来自应用程序的单个数据库请求执行许多其他操作。
存储过程下面的一层视图可用于将应用程序与模式更改和查询/连接性能调整隔离开来。
存储过程层是可靠的企业架构和框架的重要组成部分。这些存储过程应该不包含业务逻辑，当然，它们只应传递数据而不是操纵它。
为了实现这些好处，良好的规范是为了在应用程序中的所有过程中保持一致性和相同的粒度。我已经使用了许多100个程序来处理应用程序。如果所有这些查询都在代码中，那么实现数据级安全性将会更加困难，甚至是不可能的。存储过程可以很容易地生成。我觉得存储过程的总体生产率高于没有存储过程。当然，存储过程可以广告应该在源代码控制中，就像所有其他数据库对象一样。
答案 4 :(得分：6)
如果您的基础软件部署在多个不同的客户站点，则可以通过数据库（视图和存储过程）完成每个客户所需的大部分定制。您几乎可以将SP视为一个接口，来回传递标准数据，而不用担心内部发生的事情。
当然，这也可以通过其他方式处理，例如每个安装的自定义.dll数据层。
在某些情况下，SP中的自定义而不是.dll允许更快的自定义，并允许DBA或数据专家接管，让程序员继续编码。
请记住，SP中的代码可供更多人（在本例中为客户）使用，而不是编译代码。这可能是好事也可能是坏事，具体取决于你的情况。
在某些企业中，更改存储过程在政治上比重新安装软件更容易（这更多地取决于谁有更严格的规则，开发人员和项目经理，DBA或IT /服务台）。
答案 5 :(得分：4)
我的经验是，很少使用源代码控制来维护数据库，就像应用程序代码一样。当然，情况可能并非总是如此，但在15年后我从未见过它。这意味着你更有可能让人们在开发中做出改变，并且天堂禁止实时，数据库存储过程没有真正想到易于维护，因为它太容易了。
答案 6 :(得分：3)
我不反对存储过程，但我建议它们更难维护，因为它们必须独立于应用程序更新而更新（它们必须存储在sql server中）。
答案 7 :(得分：2)
根据我的经验，我认为主要的缺点是很少有与我合作的开发人员对SQL非常熟悉（首先编写它，调试它）所以你必须确保你拥有合适的技能在你的团队中设置，以便能够维护很多SQL。
如果您拥有多个平台（比如Windows和Web应用程序）或将旧应用程序移植到新技术，您可以重用数据库程序，这是一个很大的优势。
我正在使用的应用程序在存储过程中有很多业务功能，可能我们修复的一半错误在于SQL代码，如果关键可以通过替换存储过程来快速修复，而不是应用程序代码中的错误，必须等待下一个版本。 （另一方面，如果我们没有编写那么多SQL代码，那么我们可能首先会有更少的错误，谁知道呢！）
答案 8 :(得分：2)
平等，这是不好的做法，即时更改，你还记得吗？ 说真的，在存储过程中创建代码可以确保您的SQL交互更快 但您的更改离源代码控制太远了。 （对于源代码控制，你需要导出，如我所知）
答案 9 :(得分：2)
我在商业界做了10年以上的CRUD编程顾问。我可以告诉你，我把业务逻辑放在了sprocs＆amp;尽我所能（并且有意义）。每次风吹都需要改变，而数据库中的逻辑使得改变变得容易，并且（通过体面的评论）它是自我记录的。加上sprocs可以提高安全性并简化代码重用。
FWIW我在所有的sprocs上使用源代码控制和严格的测试。否则就是懒惰。
答案 10 :(得分：2)
出于多种原因，存储过程是一个好主意：
通过使业务逻辑更接近数据，您可以拥有任意数量的数据客户端接口。您最初可能会为网站设计前端，但现在他们需要报告。没问题，业务逻辑就在数据旁边。打开API，在程序前面放置一个Web服务。你想使用最热门的新语言，继续。业务逻辑紧挨着数据。
使用存储过程的另一个原因是它在您和所选数据库之间建立了强大的联系。这样，您就可以利用您所支付的数据库的内置功能（或在开源的情况下使用）。猜猜看，如果你试图使你的应用程序数据库独立，你可能会有很多难以追踪的错误。 Read consistency works differently on each vendor's database.
您可以利用数据库内置的可扩展性（集群，RAC - 但是它们实现了它）。无需自己编写。
编写不使用绑定变量的代码更加困难（如果您需要更多信息，请使用google soft parses vs hard parses）。
版本控制 - 我一直使用版本控制存储过程的公司。您通常在某些编辑器中编写存储过程。大多数编辑器现在已经内置了对至少一个主要版本控制系统的支持。
外部代码必须通过网络提取数据，然后使用它。
最后，并非所有程序语言都是平等创造的。 MySQL刚刚发布了使用存储过程的能力，它们为您提供了许多可以使用的语言，包括他们自己的语言。我怀疑他们是否支持Oracle或SQl服务器。我不打算成为最好的人，因为除了甲骨文，我不是什么专家。 Oracle的PL / SQL具有许多在DB内核中优化的功能。我确信MS SQL也能做到这一点。
希望这有用（并且有意义 - 漫长的一天）。
答案 11 :(得分：1)
通常，这个参数是因为你正在对存储过程进行临时更改，而不是通过版本控制，测试等来编译代码。
我没有立即对此做出反应（与大多数人不同），但我会说在这种类型的牛仔环境中编译和部署DLL确实不是那么难。或者，您可以使用CS-Script之类的东西，它允许您保留按需编译的原始.cs文件。
我总是发现很难对存储过程进行版本和测试，而大多数代码都很容易完成。此外，大多数RDBMS过程语言都非常原始 - 因此您不会使用当代语言为您提供的表达性或抽象性。
当然，版本控制是一件好事 - 而且，对于大多数地方，开发人员和生产之间的一些流程检查也是如此。 ;）
答案 12 :(得分：1)
在我正在工作的项目中，大多数维护只能通过更改sql程序来完成。所以，在我的情况下，存储过程更加可维护，而且它们比从代码执行sql语句具有更好的性能。
答案 13 :(得分：1)
有人会认为业务逻辑在存储过程中没有位置，导致系统无法维护。我想指出，这些论点主要来自DDD和N-Tier观点，他们寻求在应用层内的特定区域内容纳所有业务逻辑。虽然这是一个有价值的目标，但还有其他观点值得考虑。 SP还可以做很多事情，而不仅仅是容纳业务逻辑。
顺便提一下，Oracle世界认为最好的做法是在数据库中使用PL / SQL代码中的所有业务逻辑，并且他们对关系数据库知之甚少！
考虑SP的这些用法：
性能。在SP中运行多个SQL语句通常很有用，从而避免您的应用程序多次往返数据库，从而有时可以显着提高性能。
变更管理。只要您对版本控制和部署过程有所了解，SP就很容易维护和修改。
SP可以在没有中断的情况下发布到实时生产系统 ，这在24/7操作中可能是一个相当大的优势。当然，你仍然需要严格控制发布过程。
抽象层。如果所有app / db交互都是通过SP，则SP可以从应用程序中抽象出数据库模式的细节。这可能是一个非常强大的概念。考虑到数据库的生命周期通常会比应用程序更长久 - 应用程序来来去去，并且经常使用最新的技术和体系结构模式重新编写，但有价值的数据保留在相同的旧关系数据库中。通常，多个应用程序是在同一个数据库上开发的，即使这绝不是最初的意图。这些场景中的SP用于在应用和数据库之间提供紧密，定义良好的API，可以对其进行精心控制，以确保与多个应用甚至同一应用的多个版本的一致交互。
数据库模式和应用程序之间的关注点分离让应用程序员可以自由地做他们最擅长的事情，同时让DBA随时随地改进模式，而不会破坏应用程序。
无论您采用何种架构模式，SP都可以发挥重要作用。不要在任何设计中排除规则，就像任何工具一样，在有意义的地方使用它。
答案 14 :(得分：0)
我还有一件关于版本控制的事情。在我上一份工作中，我添加了第三方打包，每天运行并存储每个对象的DDL或代码的副本（如果它从上次备份时更改）。它本身就是存储过程，因此可以手动或通过触发器运行，您希望它如何运行。它本身就是一个版本控制系统。
这是一个非常好的工具，只有200美元左右。它甚至带有一个diff工具来向你展示改变了什么。
答案 15 :(得分：0)
我们已经从使用sprocs转换为基于代码的业务逻辑的生成DAL，原因有很多：
答案 16 :(得分：0)
这实际上取决于存储过程的编写程度，不是吗？如果从业者没有经过深思熟虑的编码，那么T-SQL和PL-SQL就像C＃或COBOL一样难以维护。
我最近的一个增强功能，我故意将功能放在存储过程中，主要是因为我希望功能更容易引用，更不用说维护（可以从数据库级别调用存储过程，也可以客户端级别;如果我将逻辑放在不同的层中，那就不是真的了。我认为我做得很好，使得PL-SQL相当模块化，但是当TOAD对它进行分析时，4个部分中的3个得到了很好的分数，最后一个部分因为高的圈复杂性而受到重创。嘿，我想我刚刚证明了自己的观点！
答案 17 :(得分：-1)
我认为影响这一点的一个因素是客户端数量，因为它可以在不必重新部署应用程序的情况下进行架构更改。例如。作为一名DBA，我发现调整SQL，解决错误等更容易访问一个存储过程而不是X客户端更改SQL语句，当X是一个大数字并且“访问”它们意味着部署新版本的应用程序到多个工作站。
正确完成它还意味着应用程序使用的架构可能与数据存储架构不同。例如。我喜欢高度规范化数据模式，并提供应用程序使用的一组视图和存储过程。应用程序架构随应用程序代码的更改而变化，并且与数据架构无关。这是多应用系统的真正优势（例如，一个读写应用和使用相同数据的网站应用。）
通常有一组不同的工具和用于编写存储过程的不同语言。这可能成为需要培训，技能开发等的障碍。
答案 18 :(得分：-1)
我更喜欢不使用存储过程，因为我喜欢保持相对数据库不可知。如果出现了更好的关系数据库，我希望可以选择迁移到它。存储过程会锁定你。也就是说，我偶尔使用它们，它们可以非常强大。