我正在编写一个.NET应用程序并且想知道......我应该为每个查询编写一个存储过程，还是在这里有一些拇指角色？
我知道编写SP的好处（比如安全性，不必重新编译代码来更改查询，查询编译）。
但是我发现自己很多时候我只需要对我的数据库进行简单的选择或删除操作（非常简单的东西 - 没有参数） - 所以你认为更好 - 为每个编写一个存储过程每个查询或硬编码的查询？我有一些项目，我发现自己有大量的存储过程只是因为...
由于
答案 0 :(得分：17)
存储过程引用了一些选项：
就个人而言，我很少使用sprocs。原始SQL更灵活 - 合理的c＃代码可以动态编写适当的SQL。你也可以在SQL中做到这一点，但它不适合。您还可以使用ORM等工具。更重要的是，避免了巨大的部署问题：鸡肉和鸡蛋的变化。如果sproc更改很重要，则无法在不中断调用方的情况下部署sproc，并且无法在不更新sproc的情况下更新调用方。你有多个服务器调用一个中央数据库。这意味着您需要仔细协调变更，以便两端都满意。如果查询在c＃中，则这不是问题：当您更新每个单独的服务器时，它是按照定义使用它所期望的查询版本。
基本上，我现在是直接参数化SQL的忠实粉丝。
答案 1 :(得分：1)
如果您使用存储过程并且对输入参数或返回结果进行了更改，则无论如何都会影响您的c＃代码，因此它不会影响您的代码的论点不正确。选择存储过程的人最终会在数据库中实现业务规则/逻辑，这使得很难确定对更改，调试，可跟踪性等的影响分析。
在存在复杂的数据按摩以将其呈现给消费者（没有业务逻辑）的情况下，我使用存储过程。为此目的使用Views甚至可能更好。
答案 2 :(得分：0)
对我而言，这取决于您计划如何访问数据以及您的安全问题。
如果您要使用某种数据适配器并且不需要担心安全性，那么我会说继续在您的代码中编写SQL查询。如果您担心SQL注入攻击，那么存储过程可能是更好的选择。
另一方面，如果您要使用实体框架访问数据，那么存储过程可能不是最好的方法，特别是如果您计划使用代码优先方法。使用Linq编写查询相当容易，Microsoft在将代码转换为sql方面做得不错。
也就是说，如果您打算使用EF并映射数据点，那么您可以为数据映射中的每个crud操作编写和分配存储过程，这样您就不必使用Microsoft的sql操作，如果你想在操作过程中在后端做一些额外的操作。
答案 3 :(得分：-1)
我认为编写存储过程是一个好主意，因为如果假设您必须在将来对现有查询进行一些更改或添加更多查询，那么您可以直接更改存储过程。您不必更改C＃代码并构建您的DLL。在不影响C＃代码的情况下更改存储过程中的逻辑会更容易。
此外，存储过程 MORE 可维护，因为无论何时在SQL中进行某些更改，都不必重新编译C＃代码
您可能还想查看Jeff Attwood的Stored Procedures vs. Ad-Hoc SQL和Who Needs Stored Procedures, Anyways?
答案 4 :(得分：-1)
我用于在同一存储过程中对CRUD（创建，读取，更新，删除）操作进行分组。
技巧包括添加@operation参数，并根据需要进行其他选择。
举个例子：
EXEC sp_myTable_crud @operation='C',
@id=123,
@name='mynamewithtypo',
@firstname='my first name',
@birthdate='1999-01-01'
EXEC sp_myTable_crud @operation='U',
@id=123,
@name='myname',
EXEC sp_myTable_crud @operation='R', @id = 123
EXEC sp_myTable_crud @operation='D', @id = 123
这大大减少了我在一张桌子上进行的那些琐碎的四次操作所使用的数量或存储过程。