什么是存储过程的命名约定？ [关闭] 什么是存储过程的命名约定？ [关闭](What is y

我所看到的各种规则命名的存储过程。

有些人前缀的存储过程的名称与usp_，其他与应用程序名称的缩写，还有人与所有者名称。 你不应该在SQL Server中使用以sp_，除非你真的是认真的。

一些以动词（获取，添加，保存，删除）启动PROC名称。 其他人强调实体姓名（或名称）。

在与数百个存储过程的数据库，它可以是非常难以左右滚动，并找到合适的存储过程时，你认为一个已经存在。 命名约定可以定位一个存储过程更加容易。

你使用的命名惯例？ 请描述它，并解释为什么你喜欢它比其他的选择。

回复内容：

• 每个人似乎都主张命名的一致性，即给大家使用比使用特定的一个相同的命名规则，可能更重要。
• 前缀：虽然很多人都使用usp_或类似（但很少以sp_）的东西，许多人使用数据库或应用程序的名称。 一个聪明的DBA使用根，RPT和TSK与那些用于报告或任务区分一般的CRUD存储过程。
• 动词+名词似乎略多于名词+动词更受欢迎。 有些人使用SQL关键字（SELECT，INSERT，UPDATE，DELETE）为动词，而其他使用非SQL动词（或缩写为他们）以获得更多信息和添加。 singluar和复数名词之间的一些区别，以指示是否正在被检索到的一个或多个记录。
• 一个额外的短语，建议在端部，在适当情况下。 GetCustomerById，GetCustomerBySaleDate。
• 有些人用下划线名段之间，以及一些避免下划线。 APP_ Get_Customer与appGetCustomer - 我想这是可读性的问题。
• 存储过程的大集合，可以分成Oracle包或管理工作室（SQL Server）的解决方案和项目，或SQL Server架构。
• 不可思议的缩写应避免。

为什么我选择，我做了回答：有这么多良好的反应。 谢谢你们！ 正如你所看到的，这将是非常困难的选择只有一个。 我我选择了一个共鸣。 我按照他所描述的相同的路径 - 尝试使用动词+名词，然后未能找到所有适用于客户的存储过程的。

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

因为我通常有数百存储过程的工作在非常大的应用程序，我有一个最容易找到的命名方法的偏好。 对于较小的应用程序，我会主张动词+名词，因为它遵循的方法名称的一般编码约定。

他还主张与应用程序的名称，而不是不是很有用usp_前缀。 正如一些人指出的那样，有时数据库包含多个应用程序的存储过程。 所以，随着应用程序的名称前缀有助于隔离的存储过程，并帮助数据库管理员和其他人来决定存储过程是用于该应用程序。

Answer 1:

对于我的最后一个项目，我用usp_ [动作] [对象] [进程]因此，例如，usp_AddProduct或usp_GetProductList，usp_GetProductDetail。 然而现在的数据库是在700个程序加，就变成了很多很难找到一个特定对象的所有程序。 比如我现在要寻找奇怪的获取等50个多添加程序，增加产品和50

因此在我的新的应用程序，我打算通过对象分组过程名，我也下降了USP，因为我觉得这是有些多余，除了告诉我它是一个过程，这是我可以从名称中扣除过程本身。

新的格式如下：

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

App_Tags_AddTag
App_Tags_AddTagRelations
App_Product_Add 
App_Product_GetList
App_Product_GetSingle

它有助于集团的东西更容易的发现以后，尤其是如果有大量的存储过程的。

关于在多于一个对象时，我发现大多数情况下，有一个初级和次级对象，所以主要目的是在正常情况下使用，并且次级被refered在处理部中，例如App_Product_AddAttribute。

Answer 2:

下面是一些澄清在SQL Server中以sp_前缀的问题。

与以sp_前缀命名的存储过程都存储在master数据库中存储过程的系统。

如果你给你的存储过程这个前缀，SQL Server中的主数据库中查找他们先，然后上下文数据库，从而不必要地浪费资源。 而且，如果用户创建的存储过程具有相同的名称作为一个系统存储过程，用户创建的存储过程将不会执行。

该以sp_前缀表明该存储过程是从所有数据库访问，但它应该在当前数据库的上下文中执行。

这里有一个很好的解释，其中包括性能损失的演示。

这里是由蚂蚁在评论提供了另一种有益的来源。

Answer 3:

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

我们分享在不同的，同样结构的数据库，很多存储过程，所以对于特定数据库的，我们使用的数据库名称本身的前缀; 共享程序没有前缀。 我想用不同的模式可能会得到完全摆脱这种有点丑陋前缀的替代。

前缀后的实际名称是函数的命名上没有任何差异：通常像“添加”，“设置”，“生成”，“计算”，“删除”等动词后面几个更具体的名词如“用户”， “DailyRevenues”，等等。

回应Ant的评论：

1. 表和视图之间的区别是相关的那些谁设计的数据库架构，而不是那些谁访问或修改其内容。 在需要的架构细节的罕见情况下，它很容易找到。 对于休闲SELECT查询，这是无关紧要的。 事实上，我认为能够把表和视图一样的一大优势。
2. 不像函数和存储过程，一个表或视图的名称是不可能用一个动词开始，或者是什么，但一个或多个名词。
3. 函数需要模式前缀被调用。 事实上，调用语法（即我们使用，反正）是一个功能和存储过程之间有很大不同。 但即使不是这样，同1.将适用：如果我能处理功能和存储过程一样，为什么不应该？

Answer 4:

启动存储过程的名称与sp_是SQL Server糟糕，因为该系统存储过程都以sp_开始。 因为它facilititates自动基于所述数据字典中的任务一致的命名（甚至到大地精-DOM的程度）是有用的。 因为它支持架构，可用于各类在上使用的名称前缀的方式命名空间的前缀略有SQL Server 2005中的那么有用。 例如，在一个星型模式，一个可以有暗淡和事实架构和本公约参考表。

对于存储过程，前缀是用于从系统的存储过程蔡作馨应用存储过程的目的是有用的。 up_与sp_使得它比较容易从数据字典识别非系统存储过程。

Answer 5:

TableName_WhatItDoes

• Comment_GetByID

• CUSTOMER_LIST

• UserPreference_DeleteByUserID

无前缀或愚蠢匈牙利无稽之谈。 它是最密切相关的表的只是名字，和它用来做什么的简短描述。

有一点需要注意上述：我个人一直前缀我的所有自动生成的CRUD与zCRUD_使其排序的列表，我没有看它的尽头。

Answer 6:

我已经使用了几乎所有不同系统多年来。 我终于开发这一块，这是我今天继续使用：

字首 ：

• 根 - 一般：CRUD，大多
• RPT - 报告：不言自明
• TSK - 任务：通常是一些程序性的逻辑，通过计划作业运行

动作说明：

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

（在程序做了很多事情的情况下，总体目标是用于选择行动确定。例如，客户INSERT可能需要准备工作的一个很好的协议，但总的目标是INSERT，所以“宏”被选中。

宾语：

对于根（CRUD），这是受影响的表或视图名。 对于RPT（报告），这是该报告的简短说明。 对于TSK（任务），这是任务的简短说明。

可选沉淀池：

这些是用于提高程序的理解信息可选比特。 实例包括“通过”，“为”等等

格式：

[前缀] [动作说明] [实体] [可选澄清器]

程序名称的例子：

genInsOrderHeader

genSelCustomerByCustomerID
genSelCustomersBySaleDate

genUpdCommentText

genDelOrderDetailLine

rptSelCustomersByState
rptSelPaymentsByYear

tskQueueAccountsForCollection

Answer 7:

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

命名约定是品味和你应该与所有其他开发人员在项目开始时同意的问题。

Answer 8:

用于小型数据库，我使用uspTableNameOperationName，例如uspCustomerCreate，uspCustomerDelete等，这便于通过“主”实体分组。

对于较大的数据库，添加一个架构或子系统的名称，如接收，采购，等，让他们组合在一起（因为SQL Server的喜欢的字母顺序显示它们）

我会尽量避免在名称缩写，为了清楚（对项目和新人们不必想知道“UNAICFE”表示，因为存储过程被命名为uspUsingNoAbbreviationsIncreasesClarityForEveryone）

Answer 9:

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

符号：

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

例：

P_CMS_USER_UserInfoGet

我喜欢这个符号的几个原因：

• 开始以非常简单的前缀允许代码被写入到只执行与该前缀对象beggining（以减少SQL注入，例如）
• 在我们的大环境下，多个团队正在研究其运行相同的数据库体系结构的不同的应用程序。 应用程序表示法指定哪个组拥有SP。
• 模块和名称部分只需填写层次结构。 所有名称应该能够匹配到集团/应用程序，模块，从层次结构功能。

Answer 10:

我总是用：

USP [表名称] [动作] [额外详细]

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

• uspUserCreate
• uspUserSelect
• uspUserSelectByNetworkID

该程序是按字母顺序表的名称和功能来分类，所以很容易看到什么我可以做任何给定表。 使用前缀“USP”让我知道。我打电话，如果我（例如）编写与其他程序，多个表，功能，意见和服务器交互的1000行的程序。

直到在SQL Server IDE编辑器是Visual Studio中我保持前缀为好。

Answer 11:

涉及的数据库对象的应用prefix_操作prefix_描述（减去下划线之间的空间-不得不把在他们出现空格）。

操作前缀我们使用 -

• “ 获取 ” -返回一个记录
• “ 插件 ” -插入数据
• “UPD” -更新数据
• “ 德尔 ” -删除数据

如

wmt_插件_客户_details

“人力资源管理工具，插入到细节customer表”

好处

所有涉及到相同的应用程序存储过程的名字组合在一起。 内的基团，即执行相同的操作类型的存储过程（例如插入，更新等）组合在一起。

这个制度运作良好，对我们来说，具有约。 在一个数据库中把我的头顶部1000的存储过程。

有没有遇到任何缺点这种方法至今。

Answer 12:

的getXXX - 基于@ID获取XXX

GetAllXXX - 获取所有XXX

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

DelXXX - 基于@ID删除XXX

Answer 13:

我认为usp_命名惯例确实没任何好处。

在过去，我用获取/更新/插入/删除前缀CRUD操作，但现在因为我使用LINQ到SQL或EF做我的大部分CRUD工作，这些都是完全消失。 既然我有这么几个存储特效在我的新的应用程序，命名约定不再重要，如他们用来;-)

Answer 14:

对于目前，应用我工作，我们有标识的应用程序名称（4个小写字母）的前缀。 这样做的原因是，我们的应用程序必须能够在同一个数据库中的遗留应用程序并存，因此，前缀是必须的。

如果我们没有传统的约束，我敢肯定，我们不会使用前缀。

前缀后，我们通常用来描述程序做什么动词，然后我们在经营实体的名称开始的SP名称。 实体名称的多元化，允许 - 我们试图强调可读性，因此，这是显而易见的规程，从单独的名字做什么。

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

shopGetCategories
shopUpdateItem

Answer 15:

我不认为这真的很重要的前缀也恰恰是，只要你的逻辑和一贯的。 我个人使用

spu_ [动作的说明] [过程描述]

其中，动作的描述是一个小范围的典型动作，例如获取，设置，存档，插入，删除的一个等过程的描述是短暂的东西，但描述，例如

spu_archiveCollectionData 

要么

spu_setAwardStatus

我的名字我同样的功能，但与udf_前缀

我看到有人企图利用伪匈牙利命名法的程序命名，这在我看来隐藏超过它揭示。 只要当我列出我的程序，按字母顺序，我可以看到他们的功能分组，然后对我来说，这似乎是为了和不必要的严谨性之间的甜蜜点

Answer 16:

避免在SQL Server以sp_ *堂妹所有的系统存储prcedures开始以sp_，因此成为系统更难以找到对应名称的对象。

所以，如果你用其他的东西比开始以sp_事情变得更加容易。

因此，我们使用Proc_的共同命名的开始。 这使得它更容易识别的程序，如果带有一个大的架构文件。

除此之外，我们赋予识别功能的前缀。 喜欢

Proc_Poll_Interface, Proc_Inv_Interface等。

这使我们能够找到的所有存储的特效这确实投票工作VS，做库存等。

总之前缀系统取决于你的问题域。 但人说的和做类似的话应该是现在即使只是让人们quicly定位在explorere存储过程下拉进行编辑。

其他例如函数。

Proc_Order_Place
Proc_order_Delete
Proc_Order_Retrieve
Proc_Order_History

我们遵循基于函数的命名堂妹特效是类似的代码/函数，而不是像表静态对象。 它不帮助那些特效可能与一个以上的工作表中。

如果PROC进行比可以在一个单一的名字来处理更多的功能，这意味着你的proc的方式做的比必要的，它的时间更再次分割。

希望帮助。

Answer 17:

我加入晚了线程，但我想在这里输入我的答复：

在过去两年的项目有像，在一个我们使用的是不同的发展趋势：

获取数据：■<表名> _G
要删除数据：■<表名> _D
要插入的数据：■<表名> _I
更新数据：■<表名> _U

这个命名约定也由前缀词DT遵循前端。

例：

exec sMedicationInfo_G
exec sMedicationInfo_D
exec sMedicationInfo_I
exec sMedicationInfo_U

随着我们的应用程序上面的命名约定的帮助下，我们有一个良好的，容易记忆的名字。

而在第二个项目中，我们使用莉儿差相同的命名约定：

获取数据：以sp_ <表名“G
要删除数据：以sp_ <表名> d
要插入的数据：以sp_ <表名>我
要更新的数据：以sp_ <表名>û

例：

exec sp_MedicationInfoG
exec sp_MedicationInfoD
exec sp_MedicationInfoI
exec sp_MedicationInfoU

文章来源: What is your naming convention for stored procedures? [closed]