您对存储过程的命名约定是什么？[关闭]

我已经看到了各种命名存储过程的规则。

某些人在存储过程名称前加上usp_前缀，另一些人在应用程序名称的缩写前加上前缀，而另一些人则在所有者名称前加上前缀。除非您确实如此，否则不应在SQL Server中使用sp_。

有些人以动词开头proc名称（获取，添加，保存，删除）。其他人则强调实体名称。

在具有数百个存储过程的数据库上，当您认为已经存在一个存储过程时，很难滚动查找合适的存储过程。命名约定可以使存储程序的查找更加容易。

您是否使用命名约定？请描述一下，并说明为什么您偏爱其他选择。

答复摘要：

• 似乎每个人都提倡命名的一致性，对于每个人来说，使用相同的命名约定可能比使用特定的命名约定更为重要。
• 前缀：虽然很多人使用usp_或类似名称（但很少使用sp_），但其他许多人则使用数据库或应用程序名称。一个聪明的DBA使用gen，rpt和tsk来区分一般的CRUD程序和用于报告或任务的程序。
• 动词+名词似乎比名词+动词更受欢迎。有些人为动词使用SQL关键字（“选择”，“插入”，“更新”，“删除”），而其他人则使用诸如Get和Add之类的非SQL动词（或它们的缩写）。有些人在单数名词和复数名词之间进行区分，以指示是否正在检索一个或多个记录。
• 最后在适当的地方建议添加一个短语。GetCustomerById，GetCustomerBySaleDate。
• 有些人在名称段之间使用下划线，而有些人则避免使用下划线。app_ Get_Customer与appGetCustomer-我想这是可读性的问题。
• 可以将大量的sproc隔离到Oracle软件包或Management Studio（SQL Server）解决方案和项目或SQL Server架构中。
• 应避免使用难以理解的缩写。

为什么选择我做的答案：有很多好的答案。谢谢你们！如您所见，很难只选择一个。我选择的那个引起了我的共鸣。我遵循了他描述的相同路径-尝试使用动词+名词，然后无法找到所有适用于客户的存储过程。

能够找到一个现有的存储过程，或者确定一个存储过程是否存在，这一点非常重要。如果有人无意间创建了另一个名字的重复存储过程，可能会导致严重的问题。

由于我通常在具有数百个存储库的大型应用程序上工作，因此我偏爱最容易找到的命名方法。对于较小的应用程序，我可能会提倡动词+名词，因为它遵循方法名称的通用编码约定。

他还主张使用应用程序名称作为前缀，而不是使用不太有用的usp_。正如一些人指出的那样，有时数据库包含多个应用程序的存储库。因此，使用应用程序名称作为前缀有助于隔离存储过程，并有助于DBA和其他人确定该存储过程用于哪个应用程序。

对于我的上一个项目，我使用了usp_ [Action] [Object] [Process]，例如，usp_AddProduct或usp_GetProductList，usp_GetProductDetail。但是，现在数据库有700个以上的过程，要查找特定对象上的所有过程变得更加困难。例如，我现在必须搜索50个奇数的Add过程来添加Product，而50个奇数来获取Get等。

因此，在我的新应用程序中，我计划按对象对过程名称进行分组，因为感觉有些多余，所以我也删除了usp，除了告诉我它是一个过程之外，我还可以从名称中扣除程序本身。

新格式如下

[App]_[Object]_[Action][Process]

App_Tags_AddTag
App_Tags_AddTagRelations
App_Product_Add 
App_Product_GetList
App_Product_GetSingle

它有助于对事物进行分组，以便以后查找，尤其是在有大量存储过程的情况下。

关于在多个对象上使用的对象，我发现大多数实例都有一个主对象和一个辅助对象，因此在普通实例中使用了主对象，而在处理部分中引用了辅助对象，例如App_Product_AddAttribute。

这是有关SQL Server中sp_前缀问题的一些说明。

以前缀sp_命名的存储过程是存储在Master数据库中的系统存储过程。

如果为您的sproc赋予此前缀，则SQL Server首先在Master数据库中查找它们，然后在上下文数据库中查找它们，从而不必要地浪费了资源。并且，如果用户创建的存储过程与系统存储过程具有相同的名称，则用户执行的存储过程将不会执行。

sp_前缀指示可从所有数据库访问该sproc，但应在当前数据库的上下文中执行该proc。

这是一个很好的解释，其中包括性能影响的演示。

这是 Ant在评论中提供的另一个有用的来源。

系统匈牙利语（如上面的“ usp”前缀）使我不寒而栗。

我们在不同的，结构相似的数据库中共享许多存储过程，因此对于特定于数据库的数据库，我们使用数据库名称本身的前缀；共享过程没有前缀。我想使用不同的模式可能是完全摆脱这种难看的前缀的替代方法。

前缀后面的实际名称与函数命名几乎没有什么不同：通常是动词，例如“添加”，“设置”，“生成”，“计算”，“删除”等，后跟几个更具体的名词，例如“用户” ”，“每日收入”等。

回应蚂蚁的评论：

1. 表和视图之间的差异与设计数据库模式的人员有关，而与访问或修改其内容的人员无关。在极少数需要架构细节的情况下，它很容易找到。对于临时SELECT查询，它是无关紧要的。实际上，我认为能够将表和视图视为一个很大的优势。
2. 与函数和存储过程不同，表或视图的名称不太可能以动词开头，也不能是一个或多个名词。
3. 函数需要调用架构前缀。实际上，函数和存储过程之间的调用语法（无论如何，我们都使用）非常不同。但是，即使不是，也适用与1.相同的方法：如果我可以将函数和存储过程相同，为什么不呢？

这些年来，我几乎使用了所有不同的系统。我终于开发了这个，今天继续使用：

字首 ：

• gen-General：CRUD，主要是
• rpt-报告：不言自明
• tsk-任务：通常具有程序逻辑，通过计划的作业运行

动作说明符：

Ins - INSERT
Sel - SELECT
Upd - UPDATE
Del - DELETE

（在过程执行许多操作的情况下，将使用总体目标来选择操作说明符。例如，客户INSERT可能需要进行大量准备工作，但是总体目标是INSERT，因此选择“ Ins”。

目的：

对于gen（CRUD），这是受影响的表或视图名称。对于rpt（报告），这是报告的简短描述。对于ts​​k（任务），这是任务的简短描述。

可选的澄清器：

这些是可选的信息位，用于增强对过程的理解。示例包括“按”，“用于”等。

格式：

[前缀] [动作说明符] [实体] [可选说明符]

过程名称示例：

genInsOrderHeader

genSelCustomerByCustomerID
genSelCustomersBySaleDate

genUpdCommentText

genDelOrderDetailLine

rptSelCustomersByState
rptSelPaymentsByYear

tskQueueAccountsForCollection

TableName_WhatItDoes

• Comment_GetByID

• 客户清单

• UserPreference_DeleteByUserID

没有前缀或愚蠢的匈牙利胡说八道。只是与其最相关的表的名称，以及对其作用的快速描述。

上面的一个警告：我个人总是在所有自动生成的CRUD前面加上zCRUD_，这样它就可以排在列表的末尾，而无需查看。

sp_在SQL Server中以开头的存储过程名称很不好，因为系统存储过程均以sp_开头。一致的命名（甚至在霍布林域范围内）很有用，因为它可以促进基于数据字典的自动化任务。前缀在SQL Server 2005中的用处稍差一点，因为它支持架构，该架构可以按以前使用的名称前缀的方式用于各种类型的名称空间。例如，在一个星型模式，一个可以有暗淡和事实架构和本公约参考表。

对于存储过程，前缀可用于从系统存储过程中识别应用程序存储过程。 up_vs. sp_使得从数据字典中识别非系统存储过程相对容易。

我总是将存储过程封装在软件包中（在工作中我使用的是Oracle）。这将减少单独对象的数量并帮助代码重用。

命名约定只是一个品味问题，您应该在项目开始时就与所有其他开发人员达成一致。

对于小型数据库，我使用uspTableNameOperationName，例如uspCustomerCreate，uspCustomerDelete等。这便于按“主要”实体进行分组。

对于较大的数据库，请添加架构或子系统名称，例如“接收”，“购买”等，以将它们分组在一起（因为sql server喜欢按字母顺序显示它们）

为了清楚起见，我尝试避免使用名称的缩写（项目中的新手不必怀疑'UNAICFE'的含义，因为该存储过程名为uspUsingNoAbbreviationsIncreasesClarityForEveryone）

我目前使用的格式如下

符号：

[PREFIX] [APPLICATION] [MODULE] _ [NAME]

例：

P_CMS_USER_UserInfoGet

我喜欢这种表示法的原因有几个：

• 从非常简单的Prefix开始，允许编写代码以仅执行以前缀开头的对象（例如，减少SQL注入）
• 在我们更大的环境中，多个团队正在研究运行相同数据库体系结构的不同应用程序。应用程序符号指定哪个组拥有SP。
• 模块和名称部分仅完成层次结构。所有名称都应能够与层次结构中的“组/应用程序”，“模块”，“功能”相匹配。

我一直使用：

usp [表名] [操作] [详细信息]

给定一个名为“ tblUser”的表，它给我：

• uspUserCreate
• uspUserSelect
• uspUserSelectByNetworkID

这些过程按表名和功能按字母顺序排序，因此很容易看出我可以对任何给定表执行的操作。使用前缀“ usp”可让我知道正在调用的内容（例如）正在编写与其他过程，多个表，函数，视图和服务器交互的1000行过程。

在SQL Server IDE中的编辑器与Visual Studio一样好之前，我将保留前缀。

应用程序prefix_ operation prefix_所涉及的数据库对象的描述（减去下划线之间的空格-必须在其中放置空格以使其出现）。

我们使用的操作前缀-

• “ 获取 ” –返回记录集
• “ ins ” –插入数据
• “ upd ” –更新数据
• “ 德尔 ” –删除数据

例如

wmt_ ins _客户_details

“劳动力管理工具，将详细信息插入客户表”

优点

与同一应用程序相关的所有存储过程均按名称分组。在该组中，执行相同类型操作（例如，插入，更新等）的存储过程被分组在一起。

这个系统对我们来说运作良好，大约有 在我头顶上的一个数据库中有1000个存储过程。

到目前为止，这种方法还没有遇到任何缺点。

GetXXX-根据@ID获取XXX

GetAllXXX-获取所有XXX

PutXXX-如果传递的@ID为-1，则插入XXX；否则，插入XXX。其他更新

DelXXX-根据@ID删除XXX

我认为usp_命名约定对任何人都没有好处。

过去，我对CRUD操作使用了Get / Update / Insert / Delete前缀，但是现在由于我使用Linq to SQL或EF来完成我的大多数CRUD工作，因此这些都不用了。由于我在新应用程序中存储的proc很少，因此命名约定不再像以前那样重要；-)

对于当前正在处理的应用程序，我们有一个前缀来标识应用程序名称（四个小写字母）。原因是我们的应用程序必须能够与旧应用程序在同一数据库中共存，因此前缀是必须的。

如果我们没有旧式约束，那么我很确定我们不会使用前缀。

在前缀之后，我们通常以动词开头SP，该动词描述过程的作用，然后是操作对象的名称。实体名称的复数形式是允许的-我们试图强调可读性，因此很明显，仅从名称中就可以执行该过程。

我们团队中典型的存储过程名称为：

shopGetCategories
shopUpdateItem

只要您逻辑上和一致的，我认为前缀到底是什么并不重要。我个人使用

spu_ [动作说明] [流程说明]

其中，动作描述只是一小部分典型动作之一，例如获取，设置，存档，插入，删除等。过程描述虽然简短但具有描述性，例如

spu_archiveCollectionData 

要么

spu_setAwardStatus

我用类似的方式命名函数，但以udf_作为前缀

我已经看到人们尝试将伪匈牙利符号用于过程命名，在我看来，这种命名方式隐藏的内容多于所揭示的内容。只要按字母顺序列出我的程序，我就能看到它们按功能分组，那么对我来说，这似乎是有序和不必要严格之间的最佳结合点

避免在SQl服务器中使用sp_ *，因为所有系统存储的过程都以sp_开头，因此，系统将很难找到与名称相对应的对象。

因此，如果从sp_之外的其他内容开始，事情会变得更容易。

因此，我们首先使用Proc_的通用命名。如果提供了一个大的模式文件，则可以更轻松地确定过程。

除此之外，我们还分配了一个标识功能的前缀。喜欢

Proc_Poll_Interface, Proc_Inv_Interface 等等

这使我们能够找到所有完成POLL和库存等工作的存储过程。

无论如何，前缀系统取决于您的问题域。但是al表示并做了类似的事情，即使只是为了让人们在浏览器下拉列表中快速定位存储过程以进行编辑。

其他功能。

Proc_Order_Place
Proc_order_Delete
Proc_Order_Retrieve
Proc_Order_History

我们遵循基于函数的命名方式，因为Procs类似于代码/函数，而不是像表这样的静态对象。Procs可能与多个表一起使用无济于事。

如果proc执行的功能超出单个名称所能处理的功能，则说明您的proc所执行的工作远远超出了必要，并且需要花费更多时间来拆分它们。

希望有帮助。

我参加了较晚的话题，但我想在这里输入回复：

在我的最后两个项目中，有不同的趋势，例如，在我们使用的一个中：

要获取数据：s <tablename> _G
要删除数据：s <tablename> _D
要插入数据：s <tablename> _I
要更新数据：s <tablename> _U

前端也遵循此命名约定，在单词dt之前添加前缀。

例：

exec sMedicationInfo_G
exec sMedicationInfo_D
exec sMedicationInfo_I
exec sMedicationInfo_U

在我们的应用程序中，借助上述命名约定，我们有了一个好记的名称。

在第二个项目中，我们使用相同的命名约定，但差别很小：

要获取数据：sp_ <tablename> G
要删除数据：sp_ <tablename> D
要插入数据：sp_ <tablename> I
要更新数据：sp_ <tablename> U

例：

exec sp_MedicationInfoG
exec sp_MedicationInfoD
exec sp_MedicationInfoI
exec sp_MedicationInfoU