Question

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

有些人使用usp_作为sproc名称的前缀，其他人使用应用名称的缩写作为前缀，还有其他人使用所有者名称。除非你真的想要它，否则你不应该在SQL Server中使用sp_。

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

在包含数百个sprocs的数据库中，当您认为已存在时，可能很难滚动并找到合适的sproc。命名约定可以使查找sproc变得更容易。

您使用命名约定吗？请描述一下，并解释为什么你喜欢它而不是其他选择。

回复摘要：

每个人似乎都提倡命名的一致性，每个人使用相同的命名约定可能比使用特定的命名约定更重要。
前缀：虽然很多人使用usp_或类似的东西（但很少使用sp_），但许多其他人使用数据库或应用程序名称。一个聪明的DBA使用gen，rpt和tsk来区分一般的CRUD sprocs和用于报告或任务的那些。
动词+名词似乎比Noun + Verb稍微受欢迎。有些人对动词使用SQL关键字（选择，插入，更新，删除），而其他人则使用非SQL动词（或缩写），如Get和Add。有些人区分单数和复数名词，以表明是否正在检索一个或多个记录。
在适当的情况下，最后会提出另一个短语。 GetCustomerById，GetCustomerBySaleDate。
有些人在名称段之间使用下划线，有些人则避免使用下划线。 app_ Get_Customer与appGetCustomer - 我想这是一个可读性问题。
可以将大量的sprocs分隔为Oracle包或Management Studio（SQL Server）解决方案和项目，或SQL Server模式。
应避免使用不可理解的缩写。

为什么我选择了我做的答案：有很多好的回复。谢谢你们！如你所见，选择一个是非常困难的。我选择的那个与我产生共鸣。我遵循他描述的相同路径 - 尝试使用Verb + Noun然后无法找到适用于Customer的所有sprocs。

能够找到现有的sproc，或确定是否存在，甚至非常重要。如果有人无意中创建了具有其他名称的重复sproc，则可能会出现严重问题。

由于我通常使用包含数百个sprocs的非常大的应用程序，因此我倾向于使用最容易找到的命名方法。对于较小的应用程序，我可能会提倡使用Verb + Noun，因为它遵循方法名称的一般编码约定。

他还提倡使用app name作为前缀，而不是使用不太有用的usp_。有几个人指出，有时数据库包含多个应用程序的sprocs。因此，使用app name添加前缀有助于隔离sprocs并帮助DBA和其他人确定sproc用于哪个应用程序。

Answer 1

对于我的上一个项目，我使用了usp_ [Action] [Object] [Process]，例如usp_AddProduct或usp_GetProductList，usp_GetProductDetail。但是现在数据库处于700个程序加上，在特定对象上找到所有程序变得更加困难。例如，我现在必须为Product add搜索50多个Add程序，为Get etc搜索50 odd。

因为在我的新应用程序中我正在计划按对象分组过程名称，我也放弃usp，因为我觉得它有些多余，除了告诉我它的程序，我可以从中扣除程序本身的名称。

新格式如下

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

App_Tags_AddTag
App_Tags_AddTagRelations
App_Product_Add 
App_Product_GetList
App_Product_GetSingle

它有助于将事物分组以便以后更容易找到，特别是如果存在大量的sprocs。

关于使用多个对象的位置，我发现大多数实例都有主要和次要对象，因此主要对象在普通实例中使用，而次要在进程部分中被引用，例如App_Product_AddAttribute。

Answer 2

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

使用前缀sp_命名的存储过程是存储在主数据库中的系统存储区。

如果你给你的sproc这个前缀，SQL Server首先在Master数据库中查找它们，然后在上下文数据库中查找它们，从而不必要地浪费资源。并且，如果用户创建的sproc与系统sproc具有相同的名称，则不会执行用户创建的sproc。

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

Here's一个很好的解释，其中包括演出效果的演示。

Here's Ant在评论中提供的另一个有用的来源。

Answer 3

Systems Hungarian（就像上面的“usp”前缀）让我不寒而栗。

我们在不同的，结构相似的数据库之间共享许多存储过程，因此对于特定于数据库的数据库，我们使用数据库名称本身的前缀;共享程序没有前缀。我想使用不同的模式可能是完全摆脱这些有点丑陋的前缀的替代方案。

前缀后的实际名称与功能命名几乎没有区别：通常是“添加”，“设置”，“生成”，“计算”，“删除”等动词，后跟几个更具体的名词，如作为“用户”，“每日收入”等。

回应Ant的评论：

表和视图之间的区别与设计数据库模式的人有关，而不是那些访问或修改其内容的人。在极少数需要模式细节的情况下，很容易找到。对于随意的SELECT查询，它是无关紧要的。事实上，我认为能够将表格和观点视为一个很大的优势。
与函数和存储过程不同，表或视图的名称不太可能以动词开头，或者只是一个或多个名词。
函数需要调用模式前缀。事实上，函数和存储过程之间的调用语法（无论如何我们使用）都是非常不同的。但即使它不是，也适用1.如果我可以对待函数和存储过程相同，为什么我不应该？

Answer 4

在SQL Server中使用sp_启动存储过程名称是不好的，因为系统sprocs都以sp_开头。一致的命名（甚至在hobgoblin-dom范围内）是有用的，因为它可以根据数据字典促进自动化任务。前缀在SQL Server 2005中稍微不那么有用，因为它支持模式，模式可以用于以前的名称前缀的方式用于各种类型的命名空间。例如，在星型模式中，可以使用 dim 和 fact 模式，并通过此约定引用表。

对于存储过程，前缀对于从系统sprocs中识别应用程序sprocs非常有用。 up_与sp_相比，可以相对轻松地从数据字典中识别非系统存储过程。

Answer 5

<强> TableName_WhatItDoes

Comment_GetByID
CUSTOMER_LIST
UserPreference_DeleteByUserID

没有前缀或愚蠢的匈牙利废话。只是与其关系最密切的表格的名称，以及它的作用的快速描述。

对上述内容的一个警告：我个人总是将所有自动生成的CRUD作为zCRUD_的前缀，以便排序到列表的末尾，我不必查看它。

Answer 6

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

前缀：

gen - General：CRUD，主要是
rpt - 报告：不言自明
tsk - 任务：通常采用程序逻辑，通过预定作业运行

动作说明：

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

（如果程序做了很多事情，总体目标用于选择动作说明符。例如，客户INSERT可能需要大量的准备工作，但总体目标是INSERT，所以“Ins”被选中。

对象：

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

可选的澄清剂：

这些是用于增强对程序理解的可选信息。例子包括“By”，“For”等。

格式：

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

程序名称示例：

genInsOrderHeader

genSelCustomerByCustomerID
genSelCustomersBySaleDate

genUpdCommentText

genDelOrderDetailLine

rptSelCustomersByState
rptSelPaymentsByYear

tskQueueAccountsForCollection

Answer 7

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

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

为了清晰起见，我尽量避免使用名称中的缩写（项目中的新人不必怀疑'UNAICFE'代表什么'因为sproc被命名为uspUsingNoAbbreviationsIncreasesClarityForEveryone）

Answer 8

我目前使用的格式类似于以下

符号：

[PREFIX] [应用] [MODULE] _ [NAME]

示例：

P_CMS_USER_UserInfoGet

我喜欢这种符号，原因如下：

从非常简单的Prefix开始，允许将代码写入仅执行以前缀开头的对象（例如，减少SQL注入）
在我们更大的环境中，多个团队正在开发运行相同数据库体系结构的不同应用程序。应用程序表示法指定哪个组拥有SP。
模块和名称部分只是完成了层次结构。所有名称都应该能够与heirarchy的Group / App，Module，Function相匹配。

Answer 9

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

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

Answer 10

我总是使用：

usp [表名] [行动] [额外细节]

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

uspUserCreate
uspUserSelect
uspUserSelectByNetworkID

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

直到SQL Server IDE中的编辑器与Visual Studio一样好，我保留了前缀。

Answer 11

GetXXX - 根据@ID获取XXX

GetAllXXX - 获取所有XXX

PutXXX - 如果传递@ID为-1，则插入XXX;其他更新

DelXXX - 根据@ID

删除XXX

Answer 12

application prefix_ operation prefix_涉及的数据库对象的描述（减去下划线之间的空格 - 必须为它们添加空格）。

我们使用的操作前缀 -

“ get ” - 返回记录集
“ ins ” - 插入数据
“ upd ” - 更新数据
“ del ” - 删除数据

e.g

wmt_ ins _ customer _details

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

<强>优点

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

这个系统适用于我们，约有。我的头顶上有一个数据库中的1000个存储过程。

到目前为止，这种方法没有任何不利之处。

Answer 13

避免在SQl服务器中使用sp_ *因为所有系统存储的步骤都以sp_开头，因此系统找到与该名称对应的对象变得更加困难。

因此，如果你开始使用sp_之外的其他东西变得更容易。

因此我们首先使用Proc_的通用命名。如果使用一个大的模式文件，这样可以更容易地识别过程。

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

Proc_Poll_Interface, Proc_Inv_Interface等

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

无论如何，前缀系统取决于您的问题域。但即使只是为了让人们在explorere下拉菜单中定期查找存储过程以进行编辑，也应该存在类似的东西。

其他例如功能。

Proc_Order_Place
Proc_order_Delete
Proc_Order_Retrieve
Proc_Order_History

我们遵循基于函数的命名因为Procs类似于代码/函数而不是像表这样的静态对象。它没有帮助Procs可以使用多个表。

如果proc执行的功能多于单个名称中可以处理的功能，则意味着你的proc正在执行的操作远远超过必要的时间以及再次拆分它们的时间。

希望有所帮助。

Answer 14

只要你的逻辑和一致性，我认为你的前缀是什么并不重要。我个人用

spu_ [动作描述] [过程描述]

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

spu_archiveCollectionData

或

spu_setAwardStatus

我将我的功能命名为相似，但前缀为udf _

我看到人们试图使用伪匈牙利符号进行程序命名，在我看来，隐藏的内容超出了它的显示范围。只要我按字母顺序列出我的程序，我就可以看到它们按功能分组，然后对我来说这似乎是订单和不必要的严格之间的最佳点

Answer 15

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

如果我们没有遗留约束，我很确定我们不会使用前缀。

在前缀之后，我们通常使用动词来启动SP名称，该动词描述了过程的作用，然后是我们操作的实体的名称。允许实体名称的多元化 - 我们试图强调可读性，因此很明显该程序仅从名称中做了什么。

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

shopGetCategories
shopUpdateItem

Answer 16

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

过去，我使用了Get / Update / Insert / Delete前缀来进行CRUD操作，但是现在因为我使用Linq to SQL或EF来完成我的大部分CRUD工作，所以这些都完全消失了。由于我在新应用程序中存储了很少的存储过程，因此命名约定不再像过去那样重要; - ）

Answer 17

我加入了这个帖子，但我想在这里输入我的回复：

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

获取数据：s＆lt; tablename＆gt; _G
  删除数据：s＆lt; tablename＆gt; _D
  要插入数据：s＆lt; tablename＆gt; _I
  要更新数据：s＆lt; tablename＆gt; _U

这个命名约定在前端也跟着单词 dt 加上前缀。

示例：

exec sMedicationInfo_G exec sMedicationInfo_D exec sMedicationInfo_I exec sMedicationInfo_U

在我们的应用程序的上述命名约定的帮助下，我们有一个好的，易记的名称。

在第二个项目中，我们使用了与lill不同的命名约定：


获取数据：sp_＆lt; tablename＆gt; G
  删除数据：sp_＆lt; tablename＆gt; D
  要插入数据：sp_＆lt; tablename＆gt; I
  要更新数据：sp_＆lt; tablename＆gt; U

示例：

exec sp_MedicationInfoG exec sp_MedicationInfoD exec sp_MedicationInfoI exec sp_MedicationInfoU

您对存储过程的命名约定是什么？

17 个答案: