存储过程的命名约定是什么？
我见过各种命名存储过程的规则。
有些人在存储过程名称前加上 usp_ 前缀，其他人则使用应用程序名称的缩写作为前缀，还有一些人则使用所有者名称作为前缀。 除非您确实这么想，否则不应在 SQL Server 中使用 sp_。
有些进程名称以动词开头（获取、添加、保存、删除）。 其他人则强调实体名称。
在具有数百个存储过程的数据库上，当您认为存储过程已经存在时，可能很难滚动并找到合适的存储过程。 命名约定可以使定位存储过程更加容易。
您使用命名约定吗？ 请描述它，并解释为什么您更喜欢它而不是其他选择。
回复摘要：
- 每个人似乎都提倡命名的一致性，对于每个人来说，使用相同的命名约定可能比使用特定的命名约定更重要。
- 前缀：虽然很多人使用 usp_ 或类似的名称（但很少是 sp_），但许多其他人使用数据库或应用程序名称。 一位聪明的 DBA 使用 gen、rpt 和 tsk 来区分一般的 CRUD 存储过程和用于报告或任务的存储过程。
- 动词+名词似乎比名词+动词更流行。 有些人使用 SQL 关键字（Select、Insert、Update、Delete）作为动词，而其他人则使用非 SQL 动词（或其缩写），例如 Get 和 Add。 有些区分单数和复数名词来指示是检索一个还是多个记录。
- 在适当的情况下，建议在末尾添加一个附加短语。 获取客户按 ID、获取客户按销售日期。
- 有些人在名称段之间使用下划线，有些人则避免使用下划线。 app_ Get_Customer 与 appGetCustomer ——我想这是一个可读性问题。
- 大量存储过程可以分为 Oracle 包或 Management Studio (SQL Server) 解决方案和项目，或 SQL Server 架构。
- 应避免使用难以理解的缩写。
为什么我选择这个答案：有很多好的答案。 谢谢你们！ 正如您所看到的，很难只选择一个。 我选择的那个引起了我的共鸣。 我遵循了他所描述的相同路径——尝试使用动词+名词，然后无法找到适用于客户的所有存储过程。
能够找到现有的存储过程，或者确定存储过程是否存在，非常重要。 如果有人无意中创建了具有其他名称的重复存储过程，则可能会出现严重问题。
由于我通常处理具有数百个存储过程的大型应用程序，因此我更喜欢最容易找到的命名方法。 对于较小的应用程序，我可能提倡动词 + 名词，因为它遵循方法名称的通用编码约定。
他还主张使用应用程序名称作为前缀，而不是不太有用的 usp_。 正如一些人指出的那样，有时数据库包含多个应用程序的存储过程。 因此，使用应用程序名称作为前缀有助于隔离存储过程，并帮助 DBA 和其他人确定存储过程用于哪个应用程序。
I have seen various rules for naming stored procedures.
Some people prefix the sproc name with usp_, others with an abbreviation for the app name, and still others with an owner name. You shouldn't use sp_ in SQL Server unless you really mean it.
Some start the proc name with a verb (Get, Add, Save, Remove). Others emphasize the entity name(s).
On a database with hundreds of sprocs, it can be very hard to scroll around and find a suitable sproc when you think one already exists. Naming conventions can make locating a sproc easier.
Do you use a naming convention? Please describe it, and explain why you prefer it over other choices.
Summary of replies:
- Everybody seems to advocate consistency of naming, that it might be more important for everyone to use the same naming convention than which particular one is used.
- Prefixes: While a lot of folks use usp_ or something similar (but rarely sp_), many others use database or app name. One clever DBA uses gen, rpt and tsk to distinguish general CRUD sprocs from those used for reporting or tasks.
- Verb + Noun seems to be slightly more popular than Noun + Verb. Some people use the SQL keywords (Select, Insert, Update, Delete) for the verbs, while others use non-SQL verbs (or abbreviations for them) like Get and Add. Some distinguish between singluar and plural nouns to indicate whether one or many records are being retrieved.
- An additional phrase is suggested at the end, where appropriate. GetCustomerById, GetCustomerBySaleDate.
- Some people use underscores between the name segments, and some avoid underscores. app_ Get_Customer vs. appGetCustomer -- I guess it's a matter of readability.
- Large collections of sprocs can be segregated into Oracle packages or Management Studio (SQL Server) solutions and projects, or SQL Server schemas.
- Inscrutable abbreviations should be avoided.
Why I choose the answer I did: There are SO many good responses. Thank you all! As you can see, it would be very hard to choose just one. The one I chose resonated with me. I have followed the same path he describes -- trying to use Verb + Noun and then not being able to find all of the sprocs that apply to Customer.
Being able to locate an existing sproc, or to determine if one even exists, is very important. Serious problems can arise if someone inadvertently creates a duplicate sproc with another name.
Since I generally work on very large apps with hundreds of sprocs, I have a preference for the easiest-to-find naming method. For a smaller app, I might advocate Verb + Noun, as it follows the general coding convention for method names.
He also advocates prefixing with app name instead of the not very useful usp_. As several people pointed out, sometimes the database contains sprocs for multiple apps. So, prefixing with app name helps to segregate the sprocs AND helps DBAs and others to determine which app the sproc is used for.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（17）
对于我的上一个项目，我使用了 usp_[Action][Object][Process]，例如 usp_AddProduct 或 usp_GetProductList、usp_GetProductDetail。 然而，现在数据库的程序数量已超过 700 个，查找特定对象上的所有程序变得更加困难。 例如，我现在必须为产品添加搜索 50 个奇怪的添加过程，为获取等搜索 50 个奇怪的添加过程。
因此，在我的新应用程序中，我计划按对象对过程名称进行分组，我还将 usp 删除为我觉得这有点多余，除了告诉我它是一个程序，我可以从程序本身的名称中推断出一些东西。
新格式如下
它有助于将事物分组以便以后更容易查找，特别是在存在大量存储过程的情况下。
关于使用多个对象的情况，我发现大多数实例都有主对象和次对象，因此在普通实例中使用主对象，在流程部分引用次对象，例如App_Product_AddAttribute。
For my last project i used usp_[Action][Object][Process] so for example, usp_AddProduct or usp_GetProductList, usp_GetProductDetail. However now the database is at 700 procedures plus, it becomes a lot harder to find all procedures on a specific object. For example i now have to search 50 odd Add procedures for the Product add, and 50 odd for the Get etc.
Because of this in my new application I'm planning on grouping procedure names by object, I'm also dropping the usp as I feel it is somewhat redundant, other than to tell me its a procedure, something I can deduct from the name of the procedure itself.
The new format is as follows
It helps to group things for easier finding later, especially if there are a large amount of sprocs.
Regarding where more than one object is used, I find that most instances have a primary and secondary object, so the primary object is used in the normal instance, and the secondary is refered to in the process section, for example App_Product_AddAttribute.
这里对 SQL Server 中的 sp_ 前缀问题进行一些说明。
以 sp_ 前缀命名的存储过程是存储在 Master 数据库中的系统存储过程。
如果您为存储过程指定此前缀，SQL Server 将首先在主数据库中查找它们，然后再在上下文数据库中查找，从而不必要地浪费资源。 并且，如果用户创建的存储过程与系统存储过程同名，则用户创建的存储过程将不会被执行。
sp_ 前缀表示该存储过程可从所有数据库访问，但应在当前数据库的上下文中执行。
这里有一个很好的解释，其中包括性能影响的演示。
这是 Ant 在评论中提供的另一个有用的来源。
Here's some clarification about the sp_ prefix issue in SQL Server.
Stored procedures named with the prefix sp_ are system sprocs stored in the Master database.
If you give your sproc this prefix, SQL Server looks for them in the Master database first, then the context database, thus unnecessarily wasting resources. And, if the user-created sproc has the same name as a system sproc, the user-created sproc won't be executed.
The sp_ prefix indicates that the sproc is accessible from all databases, but that it should be executed in the context of the current database.
Here's a nice explanation, which includes a demo of the performance hit.
Here's another helpful source provided by Ant in a comment.
Systems Hungarian（就像上面的“usp”前缀）让我不寒而栗。
我们在不同的、结构相似的数据库中共享许多存储过程，因此对于特定于数据库的存储过程，我们使用数据库名称本身的前缀； 共享过程没有前缀。 我想使用不同的模式可能是完全摆脱这种有点丑陋的前缀的替代方案。
前缀后面的实际名称与函数命名几乎没有什么不同：通常是一个动词，如“Add”、“Set”、“Generate”、“Calculate”、“Delete”等，后面跟着几个更具体的名词，如“User” ”、“每日收入”等等。
回应Ant的评论：
Systems Hungarian (like the above "usp" prefix) makes me shudder.
We share many stored procedures across different, similarly-structured databases, so for database-specific ones, we use a prefix of the database name itself; shared procedures have no prefix. I suppose using different schemas might be an alternative to get rid of such somewhat ugly prefixes altogether.
The actual name after the prefix is hardly different from function naming: typically a verb like "Add", "Set", "Generate", "Calculate", "Delete", etc., followed by several more specific nouns such as "User", "DailyRevenues", and so on.
Responding to Ant's comment:
TableName_WhatItDoes
Comment_GetByID
Customer_List
UserPreference_DeleteByUserID
没有前缀或愚蠢的匈牙利废话。 只是与其最密切相关的表的名称，以及对其功能的快速描述。
对上述内容的一个警告：我个人总是在所有自动生成的 CRUD 前面加上 zCRUD_ 前缀，以便它排序到列表的末尾，我不必查看它。
TableName_WhatItDoes
Comment_GetByID
Customer_List
UserPreference_DeleteByUserID
No prefixes or silly hungarian nonsense. Just the name of the table it's most closely associated with, and a quick description of what it does.
One caveat to the above: I personally always prefix all my autogenerated CRUD with zCRUD_ so that it sorts to the end of the list where I don't have to look at it.
多年来我几乎使用过所有不同的系统。 我终于开发了这个，今天继续使用：
前缀：
操作说明符：< br>
（在过程做很多事情的情况下，总体目标用于选择操作说明符。例如，客户 INSERT 可能需要大量准备工作，但总体目标是 INSERT，因此“Ins”是对象
：
报告），这是报告的简短描述 对于 tsk（任务），这是任务的简短描述。
对于 gen (CRUD)，这是受影响的表或视图名称 对于 rpt （ 说明符：
这些是可选的信息位，用于增强对过程的理解，示例包括“By”、“For”等。
格式：
[前缀][操作说明符][实体][可选说明符]
过程名称示例：
I have used pretty much all of the different systems over the years. I finally developed this one, which I continue to use today:
Prefix :
Action Specifier:
(In cases where the procedure does many things, the overall goal is used to choose the action specifier. For instance, a customer INSERT may require a good deal of prep work, but the overall goal is INSERT, so "Ins" is chosen.
Object:
For gen (CRUD), this is the table or view name being affected. For rpt (Report), this is the short description of the report. For tsk (Task) this is the short description of the task.
Optional Clarifiers:
These are optional bits of information used to enhance the understanding of the procedure. Examples include "By", "For", etc.
Format:
[Prefix][Action Specifier][Entity][Optional Clarifiers]
Examples of procedure names:
在 SQL Server 中，以
sp_开头的存储过程名称是不好的，因为系统存储过程都以 sp_ 开头。 一致的命名（甚至在 hobgoblin-dom 的范围内）很有用，因为它有利于基于数据字典的自动化任务。 前缀在 SQL Server 2005 中的用处稍显不足，因为它支持架构，可以像名称前缀一样用于各种类型的名称空间。 例如，在星型模式上，可以有 dim 和 fact 模式，并通过此约定引用表。对于存储过程，前缀对于从系统存储过程中识别应用程序存储过程很有用。
up_与sp_相比，可以相对轻松地从数据字典中识别非系统存储过程。Starting a stored procedure name with
sp_is bad in SQL Server because the system sprocs all start with sp_. Consistent naming (even to the extent of hobgoblin-dom) is useful because it facilititates automated tasks based on the data dictionary. Prefixes are slightly less useful in SQL Server 2005 as it supports schemas, which can be used for various types of namespaces in the way that prefixes on names used to. For example, on a star schema, one could have dim and fact schemas and refer to tables by this convention.For stored procedures, prefixing is useful for the purpose of indentifying application sprocs from system sprocs.
up_vs.sp_makes it relatively easy to identify non-system stored procedures from the data dictionary.对于小型数据库，我使用uspTableNameOperationName，例如uspCustomerCreate、uspCustomerDelete等。这有助于按“主”实体进行分组。
对于较大的数据库，添加模式或子系统名称，例如接收、采购等，以将它们分组在一起（因为 sql server 喜欢按字母顺序显示它们），
为了清楚起见，我尽量避免名称中的缩写（以及新人在项目不必想知道“UNAICFE”代表什么，因为存储过程被命名为 uspUsingNoAbbreviationsIncreasesClarityForEveryone）
for small databases, i use uspTableNameOperationName, e.g. uspCustomerCreate, uspCustomerDelete, etc. This facilitates grouping by 'main' entity.
for larger databases, add a schema or subsystem name, e.g. Receiving, Purchasing, etc. to keep them grouped together (since sql server likes to display them alphabetically)
i try to avoid abbreviations in the names, for clarity (and new people on the project don't have to wonder what 'UNAICFE' stands for because the sproc is named uspUsingNoAbbreviationsIncreasesClarityForEveryone)
我总是将存储过程封装在包中（我在工作中使用Oracle）。 这将减少单独对象的数量并有助于代码重用。
命名约定是一个品味问题，您应该在项目开始时与所有其他开发人员达成一致。
I always encapsulate the stored procedures in packages (I'm using Oracle, at work). That will reduce the number of separate objects and help code reuse.
The naming convention is a matter of taste and something you should agree with all the other developers at project start.
我目前使用的格式类似于以下
表示法：
[PREFIX][APPLICATION][MODULE]_[NAME]
示例：
P_CMS_USER_UserInfoGet
我喜欢这种表示法有几个原因：
I currently use a format which is like the following
Notation:
[PREFIX][APPLICATION][MODULE]_[NAME]
Example:
P_CMS_USER_UserInfoGet
I like this notation for a few reasons:
我总是使用：
usp[Table Name][Action][Extra Detail]
给定一个名为“tblUser”的表，它给我：
这些过程按表名称和功能按字母顺序排序，因此很容易看到我的内容可以对任何给定的表执行操作。 如果我（例如）正在编写一个与其他过程、多个表、函数、视图和服务器交互的 1000 行过程，则使用前缀“usp”可以让我知道我在调用什么。
在 SQL Server IDE 中的编辑器与 Visual Studio 一样好之前，我将保留前缀。
I always use:
usp[Table Name][Action][Extra Detail]
Given a table called "tblUser", that gives me:
The procedures are alphabetically sorted by table name and by functionality, so it's easy to see what I can do to any given table. Using the prefix "usp" lets me know what I'm calling if I'm (for example) writing a 1000-line procedure that interacts with other procedures, multiple tables, functions, views and servers.
Until the editor in the SQL Server IDE is as good as Visual Studio I'm keeping the prefixes.
应用程序前缀_操作前缀_涉及的数据库对象的描述（减去下划线之间的空格 - 必须在其中添加空格才能显示）。
我们使用的操作前缀 -
例如
wmt_ ins _ customer_details
“劳动力管理工具，将详细信息插入客户表”
优点
所有存储过程与同一应用程序相关的内容按名称分组在一起。 在该组内，执行相同类型操作（例如插入、更新等）的存储过程被分组在一起。
该系统对我们来说运行良好，大约有。 一个数据库中的 1000 个存储过程让我浮想联翩。
到目前为止，还没有发现这种方法有任何缺点。
application prefix_ operation prefix_ description of database objects involved (minus the spaces between underscores - had to put spaces in for them to appear).
operation prefixes we use -
e.g
wmt_ ins _ customer _details
"workforce management tool, insert details into customer table"
advantages
All stored procedures relating to the same application are grouped together by name. Within the group, stored procedures that carry out the same kind of operation (e.g. inserts, updates, etc.) are grouped together.
This system works well for us, having approx. 1000 stored procedures in one database off the top of my head.
Haven't come across any disadvantages to this approach so far.
GetXXX - 根据@ID 获取XXX
GetAllXXX - 获取所有XXX
PutXXX - 如果传递的@ID 为-1，则插入XXX； else 更新
DelXXX - 根据@ID 删除 XXX
GetXXX - Gets XXX based on @ID
GetAllXXX - Gets all XXX
PutXXX - Inserts XXX if passed @ID is -1; else updates
DelXXX - Deletes XXX based on @ID
我认为 usp_ 命名约定对任何人都没有任何好处。
过去，我使用 Get/Update/Insert/Delete 前缀进行 CRUD 操作，但现在由于我使用 Linq to SQL 或 EF 来完成大部分 CRUD 工作，这些前缀完全消失了。 由于我的新应用程序中的存储过程很少，因此命名约定不再像以前那样重要;-)
I think the usp_ naming convention does nobody any good.
In the past, I've used Get/Update/Insert/Delete prefixes for CRUD operations, but now since I use Linq to SQL or the EF to do most of my CRUD work, these are entirely gone. Since I have so few stored procs in my new applications, the naming conventions no longer matter like they used to ;-)
对于我当前正在开发的应用程序，我们有一个标识应用程序名称的前缀（四个小写字母）。 这样做的原因是我们的应用程序必须能够与同一数据库中的旧应用程序共存，因此前缀是必须的。
如果我们没有遗留约束，我很确定我们不会使用前缀。
在前缀之后，我们通常以描述过程功能的动词开始 SP 名称，然后是我们操作的实体的名称。 允许实体名称的复数形式 - 我们尝试强调可读性，以便仅从名称就可以清楚地看出该过程的作用。
我们团队中典型的存储过程名称是：
For the current, application I am working on, we have a prefix that identifies the application name (four lowercase letters). The reason for this is that our application must be able to co-exist with a legacy application in the same database, so the prefix is a must.
If we did not have the legacy constraint, I am quite sure that we would not be using a prefix.
After the prefix we usually start the SP name with a verb that describes what the procedure does, and then the name of the entity that we operate on. Pluralization of the entity name is allowed - We try to emphasize readability, so that it is obvious what the procedure does from the name alone.
Typical stored procedure names on our team would be:
我认为只要你的逻辑性和一致性，你的前缀是什么并不重要。 我个人使用
spu_[动作描述][流程描述]
，其中动作描述是一小部分典型操作之一，例如获取、设置、归档、插入、删除等。流程描述简短但具有描述性，例如
或
我类似地命名我的函数，但前缀为 udf_
我见过人们尝试使用伪匈牙利表示法来命名过程，在我看来，这隐藏的东西比它揭示的东西多。 只要当我按字母顺序列出程序时，我可以看到它们按功能分组，那么对我来说，这似乎是顺序和不必要的严格性之间的最佳点
I don't think it really matters precisely what your prefix is so long as you're logical and consistent. Personally I use
spu_[action description][process description]
where action description is one of a small range of typical actions such as get, set, archive, insert, delete etc. The process description is something short but descriptive, for example
or
I name my functions similarly, but prefix with udf_
I have seen people attempt to use pseudo-Hungarian notation for procedure naming, which in my opinion hides more than it reveals. So long as when I list my procedures alphabetically I can see them grouped by functionality then for me that seems to be the sweet spot between order and unnecessary rigour
在 SQl 服务器中避免使用 sp_*，因为所有系统存储过程都以 sp_ 开头，因此系统更难找到与该名称相对应的对象。
因此，如果你从 sp_ 以外的东西开始，事情就会变得更容易。
因此我们首先使用 Proc_ 的通用命名。 如果提供一个大模式文件，则可以更轻松地识别过程。
除此之外，我们分配一个标识该函数的前缀。 像
Proc_Poll_Interface、Proc_Inv_Interface 等。
这使我们能够找到所有执行 POLL 工作和执行 Inventory 等工作的存储过程。
无论如何，前缀系统取决于您的问题域。 但 al said and did 类似的东西应该存在，即使它只是为了让人们在资源管理器下拉列表中快速找到存储过程以进行编辑。
其他例如功能。
我们遵循基于函数的命名，因为过程类似于代码/函数，而不是像表这样的静态对象。 Procs 可能与多个表一起工作并没有什么帮助。
如果 proc 执行的功能多于单个名称所能处理的功能，则意味着您的 proc 执行的功能远远超出了必要的范围，是时候再次拆分它们了。
希望有帮助。
Avoid sp_* in SQl server coz all system stored prcedures begins with sp_ and therefore it becomes more harder for the system to find the object corresponding to the name.
So if you begin with something other than sp_ things become easier.
So we use a common naming of Proc_ to begin with. That makes it easier to identify the procedures if presented with one big schema file.
Apart from that we assign a prefix that identify the function. Like
Proc_Poll_Interface, Proc_Inv_Interfaceetc.This allows us to find all stored procs which does the job of POLL vs that does Inventory etc.
Anyhow the prefix system depends on your problem domain. But al said and done something similar ought to be present even if it be just to allow people to quicly locate the stored procedure in the explorere drop down for editing.
other eg's of function.
We followed the function based naming coz Procs are akin to code / function rather than static objects like tables. It doesnt help that Procs might work with more than one table.
If the proc performed more functions than can be handled in a single name, it means your proc is doing way much more than necessary and its time to split them again.
Hope that helps.
我加入得很晚，但我想在这里输入我的回复：
在我最近的两个项目中，有不同的趋势，例如我们使用的一个：
在前端也遵循此命名约定，添加前缀单词 dt。
示例：
在我们的应用程序中的上述命名约定的帮助下，我们有了一个好记且易于记住的名称。
在第二个项目中，我们使用了相同的命名约定，但略有不同：
示例：
I joined late the thread but I want to enter my reply here:
In my last two projects there are different trends like, in one we used:
This naming conventions is also followed in front-end by prefixing the word dt.
Example:
With the help of above naming conventions in our application we have a good and easy to remember names.
While in second project we used the same naming conventions with lill difference:
Example: