I have worked with several big databases and the names of stored procedures were very different:
我曾与几个大型数据库合作，存储过程的名称非常不同：
SP_PrefixXXX
PrefixYyyXxx
Prefix: Rep, Act
What's the best practice of naming? How can I organize them in a proper way?
命名的最佳做法是什么？我怎样才能以正确的方式组织它们？
10 个解决方案
#1
51
The sp_ prefix stands for System Procedure, and it should not be used as prefix for regular procedures. If you do, it will first make an extra trip to the master database each time to look for the procedure, and if it would have the same name as one of the procedures there, that procedure will be executed instead of your procedure.
sp_前缀代表系统过程，不应将其用作常规过程的前缀。如果这样做，它将首先在每次查找过程时多次访问master数据库，如果它与其中一个过程具有相同的名称，则将执行该过程而不是您的过程。
Other than that, you are free to make up any naming convention you like. One used by our company is subsystem_object_action, e.g. main_Customer_Get. That puts procedures that belong together close to each other in the listing.
除此之外，您可以*地编写您喜欢的任何命名约定。我们公司使用的是subsystem_object_action，例如main_Customer_Get。这使得属于一起的过程在列表中彼此接近。
#2
7
The best naming convention is the one that is consistent throughout your database :)
最好的命名约定是整个数据库中一致的:)
Really, it's up to you and your team. So long as it's clear and sensible, you have a fair bit of leeway. Just make sure that whatever you decide on, everyone adheres to it. Far more important than the convention itself is the fact that everyone sticks with it.
真的，这取决于你和你的团队。只要它清晰明了，你就有一点余地。只要确保无论你决定什么，每个人都坚持它。比大会本身更重要的是每个人都坚持下去。
I tend to avoid sp_, usp_ and the like, because I find them redundant. For instance, a sproc called InsertCustomer is clearly a sproc, and in no way could be confused for a table, view, or any other sort of object. sp_ in particular should be avoided.
我倾向于避免使用sp_，usp_等，因为我发现它们是多余的。例如，名为InsertCustomer的sproc显然是一个sproc，并且绝不会混淆表，视图或任何其他类型的对象。特别是应该避免使用sp_。
I prefer CamelCase, but again, that's a matter of preference. I like my proc name to give a good indication of what the proc does - for instance:
我更喜欢CamelCase，但同样，这是一个偏好问题。我喜欢我的proc名称，以便很好地指示proc的作用 - 例如：
InsertSalesOrder PopulateItemStagingTables CalculateOrderSummary PrepareCustomerStatements
InsertSalesOrder PopulateItemStagingTables CalculateOrderSummary PrepareCustomerStatements
etc.
等等
#3
7
I like prefixing them so SP's dealing with specific objects are grouped together. So instead of something like:
我喜欢为它们添加前缀，因此SP处理特定对象的组合在一起。所以不是这样的：
InsertUser
UpdateUser
DeleteUser
GetUsers
I do it like this:
我是这样做的：
AppName_User_GetUser
AppName_User_InsertUser
AppName_User_UpdateUser
AppName_User_DeleteUser
I find this is easier for me to manage in my SQL management app and in my code too.
我发现这对我来说更容易在我的SQL管理应用程序和代码中进行管理。
Like the other folks said, don't prefix with sp_
像其他人说的那样，不要用sp_作为前缀
#4
6
I don't know if there really is a specific 'best practice' in this case. With the company I am at now, the standard is usp[ProcedureName] (no underscore). I would personally prefer no prefix at all, but if you are coming in new to a company or project and they have pre-existing standards, unless they are using sp_ where there is a technical reason not to use this, it is probably not an issue worth debating as I certainly don't think it is in this case at all an egregious standard.
我不知道在这种情况下是否确实存在特定的“最佳实践”。对于我现在的公司，标准是usp [ProcedureName]（没有下划线）。我个人不会喜欢任何前缀，但是如果你是一个公司或项目的新手并且他们有预先存在的标准，除非他们使用sp_哪里有技术原因不使用它，它可能不是这个问题值得辩论，因为我当然不认为在这种情况下是一个令人震惊的标准。
Generally re naming conventions, if you do have a debate and other team members disagree with you and the consensus standard is different, the best policy is to quickly let it go and accept the consensus; consistency is generally more important than the actual standard itself, as is getting along well with other team members and not developing a reputation for being 'difficult'.
一般来说，重新命名惯例，如果你确实有辩论而其他团队成员不同意你，而且共识标准不同，那么最好的政策就是尽快让它去接受共识;一致性通常比实际标准本身更重要，因为它与其他团队成员相处得很好而没有因“困难”而声名远扬。
#5
6
Not "sp_", nor "usp_". We know they're stored procedures, the naming scheme doesn't need to tell us.
不是“sp_”，也不是“usp_”。我们知道它们是存储过程，命名方案不需要告诉我们。
I generally just name them for what they do, possibly partitioning them on schemas. The exceptions are that I will use an "ssis_" prefix for stored procedures which aren't directly used as part of the "normal" database operations, but which are used by an SSIS package to reference the database. I may use "fn_" to indicate a function, to distinguish it from a stored procedure.
我通常只是为他们所做的事情命名，可能在模式上将它们分区。例外情况是我将对存储过程使用“ssis_”前缀，这些存储过程不直接用作“正常”数据库操作的一部分，但是SSIS包用它来引用数据库。我可以使用“fn_”来表示一个函数，以区别于存储过程。
#6
2
Well, prefixing the name with "SP_" is pretty much redundant: it's naming for the implementation (it's an SP, as opposed to a table or a view). There are plenty of other ways (systebales, information_schema, how you use it) that will tell you hw it's implemented.
好吧，在名称前添加“SP_”几乎是多余的：它是为实现命名的（它是一个SP，而不是一个表或一个视图）。还有很多其他的方法（systebales，information_schema，你如何使用它）会告诉你它已经实现了。
Instead you should name it for its interface, for what it does for you. For convenience (as many things end up ordered alphabetically), I like to group like things under like names, possibly using the same prefix.
相反，你应该为它的界面命名它，为它做什么。为了方便起见（因为很多事情最终按字母顺序排序），我喜欢用类似的名字分组，可能使用相同的前缀。
But again, name it for what it does, not how it happens to be implemented.
但是，再次命名它的作用，而不是它是如何实现的。
In general, I find that the common naming conventions for database objects use underscores instead of CamelCase; this is just a matter of convention. What is not mere convention is the also common convention of using all lowercase letters for database objects; this allows you to ignore server settings which may or may not be case-insensitive.
通常，我发现数据库对象的常见命名约定使用下划线而不是CamelCase;这只是一个惯例问题。不仅仅是约定的是使用全部小写字母表示数据库对象的常见惯例;这允许您忽略服务器设置，这些设置可能不区分大小写，也可能不区分大小写。
#7
1
I tend to try to give names that not only give an idea what the function is for, but what the input variables will be.
我倾向于尝试给出名称，不仅可以了解函数的用途，还有输入变量的含义。
For example: ProcessMathEquationWithFieldIdPlantId
例如：ProcessMathEquationWithFieldIdPlantId
This will help give information immediately to anyone else using it, I believe.
我相信，这将有助于立即向使用它的任何人提供信息。
I also avoid sp_ and usp_ to limit any chance of name collisions.
我还避免使用sp_和usp_来限制名称冲突的可能性。
#8
0
Im not a pro but i like this way
我不是专业人士，但我喜欢这样
Prefix of application = XY; View = v; Stored Procedure = p; Function = f
应用前缀= XY; View = v;存储过程= p;功能= f
Table: XY_Name
View: vXY_Name
Procedure: sXY_Name
Function: fXY_Name
What do you think ? I know some people use the two characters for identifying object type but one character is enough for most cases, right ?
你怎么看 ？我知道有些人使用这两个字符来识别对象类型，但对于大多数情况，一个字符就够了，对吗？
#9
0
Better create schema for seperate module.
更好地为单独的模块创建模式。
Then Give Meaningful and simple name.
然后给出有意义且简单的名字。
For Example: if you are working school project.
例如：如果你正在上学项目。
create Student schema
创建学生模式
procedure name :AddStudent
过程名称：AddStudent
So it will look like Student.AddStudent in procedurelist
因此它在procedurelist中看起来像Student.AddStudent
same thing for Teacher Module
教师模块也是如此
#10
0
This may help. As I am front/backend programmer, I use the following for both MySQL and SQLServer:
这可能有所帮助。由于我是前端/后端程序员，我对MySQL和SQLServer使用以下内容：
SPx_PAGE/MODULE_ACTION_OBJECT
x: R for read, I for insert, U for update, W for write (combines insert if index not exists or update if exists) and D for delete.
x：R表示读取，I表示插入，U表示更新，W表示写入（如果索引不存在则组合插入，如果存在则组合更新）和D表示删除。
page/module: the place who calls the procedure
page / module：调用该过程的地方
Examples:
例子：
SPR_DASHBOARD_GET_USERS //reads users data
SPW_COMPANIES_PUT_COMPANY //creates or modifies a company
#1
51
The sp_ prefix stands for System Procedure, and it should not be used as prefix for regular procedures. If you do, it will first make an extra trip to the master database each time to look for the procedure, and if it would have the same name as one of the procedures there, that procedure will be executed instead of your procedure.
sp_前缀代表系统过程，不应将其用作常规过程的前缀。如果这样做，它将首先在每次查找过程时多次访问master数据库，如果它与其中一个过程具有相同的名称，则将执行该过程而不是您的过程。
Other than that, you are free to make up any naming convention you like. One used by our company is subsystem_object_action, e.g. main_Customer_Get. That puts procedures that belong together close to each other in the listing.
除此之外，您可以*地编写您喜欢的任何命名约定。我们公司使用的是subsystem_object_action，例如main_Customer_Get。这使得属于一起的过程在列表中彼此接近。
#2
7
The best naming convention is the one that is consistent throughout your database :)
最好的命名约定是整个数据库中一致的:)
Really, it's up to you and your team. So long as it's clear and sensible, you have a fair bit of leeway. Just make sure that whatever you decide on, everyone adheres to it. Far more important than the convention itself is the fact that everyone sticks with it.
真的，这取决于你和你的团队。只要它清晰明了，你就有一点余地。只要确保无论你决定什么，每个人都坚持它。比大会本身更重要的是每个人都坚持下去。
I tend to avoid sp_, usp_ and the like, because I find them redundant. For instance, a sproc called InsertCustomer is clearly a sproc, and in no way could be confused for a table, view, or any other sort of object. sp_ in particular should be avoided.
我倾向于避免使用sp_，usp_等，因为我发现它们是多余的。例如，名为InsertCustomer的sproc显然是一个sproc，并且绝不会混淆表，视图或任何其他类型的对象。特别是应该避免使用sp_。
I prefer CamelCase, but again, that's a matter of preference. I like my proc name to give a good indication of what the proc does - for instance:
我更喜欢CamelCase，但同样，这是一个偏好问题。我喜欢我的proc名称，以便很好地指示proc的作用 - 例如：
InsertSalesOrder PopulateItemStagingTables CalculateOrderSummary PrepareCustomerStatements
InsertSalesOrder PopulateItemStagingTables CalculateOrderSummary PrepareCustomerStatements
etc.
等等
#3
7
I like prefixing them so SP's dealing with specific objects are grouped together. So instead of something like:
我喜欢为它们添加前缀，因此SP处理特定对象的组合在一起。所以不是这样的：
InsertUser
UpdateUser
DeleteUser
GetUsers
I do it like this:
我是这样做的：
AppName_User_GetUser
AppName_User_InsertUser
AppName_User_UpdateUser
AppName_User_DeleteUser
I find this is easier for me to manage in my SQL management app and in my code too.
我发现这对我来说更容易在我的SQL管理应用程序和代码中进行管理。
Like the other folks said, don't prefix with sp_
像其他人说的那样，不要用sp_作为前缀
#4
6
I don't know if there really is a specific 'best practice' in this case. With the company I am at now, the standard is usp[ProcedureName] (no underscore). I would personally prefer no prefix at all, but if you are coming in new to a company or project and they have pre-existing standards, unless they are using sp_ where there is a technical reason not to use this, it is probably not an issue worth debating as I certainly don't think it is in this case at all an egregious standard.
我不知道在这种情况下是否确实存在特定的“最佳实践”。对于我现在的公司，标准是usp [ProcedureName]（没有下划线）。我个人不会喜欢任何前缀，但是如果你是一个公司或项目的新手并且他们有预先存在的标准，除非他们使用sp_哪里有技术原因不使用它，它可能不是这个问题值得辩论，因为我当然不认为在这种情况下是一个令人震惊的标准。
Generally re naming conventions, if you do have a debate and other team members disagree with you and the consensus standard is different, the best policy is to quickly let it go and accept the consensus; consistency is generally more important than the actual standard itself, as is getting along well with other team members and not developing a reputation for being 'difficult'.
一般来说，重新命名惯例，如果你确实有辩论而其他团队成员不同意你，而且共识标准不同，那么最好的政策就是尽快让它去接受共识;一致性通常比实际标准本身更重要，因为它与其他团队成员相处得很好而没有因“困难”而声名远扬。
#5
6
Not "sp_", nor "usp_". We know they're stored procedures, the naming scheme doesn't need to tell us.
不是“sp_”，也不是“usp_”。我们知道它们是存储过程，命名方案不需要告诉我们。
I generally just name them for what they do, possibly partitioning them on schemas. The exceptions are that I will use an "ssis_" prefix for stored procedures which aren't directly used as part of the "normal" database operations, but which are used by an SSIS package to reference the database. I may use "fn_" to indicate a function, to distinguish it from a stored procedure.
我通常只是为他们所做的事情命名，可能在模式上将它们分区。例外情况是我将对存储过程使用“ssis_”前缀，这些存储过程不直接用作“正常”数据库操作的一部分，但是SSIS包用它来引用数据库。我可以使用“fn_”来表示一个函数，以区别于存储过程。
#6
2
Well, prefixing the name with "SP_" is pretty much redundant: it's naming for the implementation (it's an SP, as opposed to a table or a view). There are plenty of other ways (systebales, information_schema, how you use it) that will tell you hw it's implemented.
好吧，在名称前添加“SP_”几乎是多余的：它是为实现命名的（它是一个SP，而不是一个表或一个视图）。还有很多其他的方法（systebales，information_schema，你如何使用它）会告诉你它已经实现了。
Instead you should name it for its interface, for what it does for you. For convenience (as many things end up ordered alphabetically), I like to group like things under like names, possibly using the same prefix.
相反，你应该为它的界面命名它，为它做什么。为了方便起见（因为很多事情最终按字母顺序排序），我喜欢用类似的名字分组，可能使用相同的前缀。
But again, name it for what it does, not how it happens to be implemented.
但是，再次命名它的作用，而不是它是如何实现的。
In general, I find that the common naming conventions for database objects use underscores instead of CamelCase; this is just a matter of convention. What is not mere convention is the also common convention of using all lowercase letters for database objects; this allows you to ignore server settings which may or may not be case-insensitive.
通常，我发现数据库对象的常见命名约定使用下划线而不是CamelCase;这只是一个惯例问题。不仅仅是约定的是使用全部小写字母表示数据库对象的常见惯例;这允许您忽略服务器设置，这些设置可能不区分大小写，也可能不区分大小写。
#7
1
I tend to try to give names that not only give an idea what the function is for, but what the input variables will be.
我倾向于尝试给出名称，不仅可以了解函数的用途，还有输入变量的含义。
For example: ProcessMathEquationWithFieldIdPlantId
例如：ProcessMathEquationWithFieldIdPlantId
This will help give information immediately to anyone else using it, I believe.
我相信，这将有助于立即向使用它的任何人提供信息。
I also avoid sp_ and usp_ to limit any chance of name collisions.
我还避免使用sp_和usp_来限制名称冲突的可能性。
#8
0
Im not a pro but i like this way
我不是专业人士，但我喜欢这样
Prefix of application = XY; View = v; Stored Procedure = p; Function = f
应用前缀= XY; View = v;存储过程= p;功能= f
Table: XY_Name
View: vXY_Name
Procedure: sXY_Name
Function: fXY_Name
What do you think ? I know some people use the two characters for identifying object type but one character is enough for most cases, right ?
你怎么看 ？我知道有些人使用这两个字符来识别对象类型，但对于大多数情况，一个字符就够了，对吗？
#9
0
Better create schema for seperate module.
更好地为单独的模块创建模式。
Then Give Meaningful and simple name.
然后给出有意义且简单的名字。
For Example: if you are working school project.
例如：如果你正在上学项目。
create Student schema
创建学生模式
procedure name :AddStudent
过程名称：AddStudent
So it will look like Student.AddStudent in procedurelist
因此它在procedurelist中看起来像Student.AddStudent
same thing for Teacher Module
教师模块也是如此
#10
0
This may help. As I am front/backend programmer, I use the following for both MySQL and SQLServer:
这可能有所帮助。由于我是前端/后端程序员，我对MySQL和SQLServer使用以下内容：
SPx_PAGE/MODULE_ACTION_OBJECT
x: R for read, I for insert, U for update, W for write (combines insert if index not exists or update if exists) and D for delete.
x：R表示读取，I表示插入，U表示更新，W表示写入（如果索引不存在则组合插入，如果存在则组合更新）和D表示删除。
page/module: the place who calls the procedure
page / module：调用该过程的地方
Examples:
例子：
SPR_DASHBOARD_GET_USERS //reads users data
SPW_COMPANIES_PUT_COMPANY //creates or modifies a company