使用存储过程是否是不好的做法？ [英] Is the usage of stored procedures a bad practice?

问题描述

我们有一个用C＃编写的应用程序，该应用程序连接到ms sql服务器。
我们用来为每个数据库调用创建一个存储过程，但是然后我们注意到，使用存储过程给我们带来了很大的不利，我们不知道如果更改数据库，我们需要更新哪些存储过程。

We have an application that is written in C# that is connected to a ms sql server. We use to make a stored procedure for every database call, but then we've noticed that using stored procedures gives us a very big disadvantage, we don't know what stored procedures we need to update if we change our database.

现在我想知道使用存储过程是一件坏事还是一件好事？

Now I was wondering if using stored procedures is a bad thing or a good thing?

推荐答案

这不是SP问题，而是开发过程中的问题。如果您没有信息，则只需获取它即可。

That's not a SP problem, that's an issue of your development process. If you have no information you need - just get it.

您可以制作一个简单的可视化地图，显示您的表架构和相关的SP。如果您的数据库太大而无法进行可视化映射，请添加包含SP和所依赖表名称的通用文本文件。

You can make a simple visual map that shows your table schema and dependant SPs. If your DB is too large for visual mapping, add common text file that consists of your SPs and names of tables it depends upon.

无论如何，数据库越大，将模式的详细信息内联到应用程序代码中时，您的工作将变得更糟。当您使用SP时，您保证不会将此功能加倍，并且大多数更改将在没有应用程序重新编译和重新分发的情况下在数据库端进行。

Anyway, the bigger your DB is, the worse will be your job when inlining details of your schema into your application code. When you use SP you guarantee that this functionality won't be doubled and that most changes will occur on DB side without application recompilation and redistribution.

更新

Upd

我忘了提到另一件事。好的数据库工具为查找每个SP的依赖表提供了简便的方法。例如，Microsoft SQL Management Studio的SP上下文菜单中有查看依赖项项。

I forgot to mention one other thing. Good DB tools provide easy way to find dependant tables for each SP. There's 'View Dependencies' item in SP context menu in Microsoft SQL Management Studio, for example.

这篇关于使用存储过程是否是不好的做法？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！