存储过程的变数命名原则是什么？

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

有些人用 usp _ 作为 sproc 名称的前缀，有些人用应用程序名称的缩写作为前缀，还有一些人用所有者名称作为前缀。在 SQLServer 中不应该使用 sp _，除非您是认真的。

有些 proc 名称以动词开头(获取、添加、保存、删除) ，有些则强调实体名称。

在一个有数百个 sproc 的数据库中，当您认为一个 sproc 已经存在时，很难滚动并找到合适的 sproc。命名约定可以简化 sproc 的定位。

你用变数命名原则吗? 请描述一下，并解释一下为什么你更喜欢它而不是其他选择。

答复摘要:

  • 每个人似乎都主张命名的一致性，对每个人来说，使用相同的变数命名原则可能比使用特定的名称更重要。
  • 前缀: 虽然很多人使用 usp _ 或类似的名称(但很少使用 sp _) ，但也有很多人使用数据库或应用程序名称。一个聪明的 DBA 使用 gen、 rpt 和 tsk 来区分常规 CRUD sprocs 和用于报告或任务的 sprocs。
  • 动词 + 名词似乎比名词 + 动词稍微流行一些。有些人使用 SQL 关键字(选择、插入、更新、删除)作为动词，而其他人使用非 SQL 动词(或它们的缩写) ，如 Get 和 Add。有些人区分单数名词和复数名词，以指示是否检索一个或多个记录。
  • 在适当的地方，在结尾处建议添加一个短语。
  • 有些人在名称段之间使用下划线，有些人避免使用下划线。App _ Get _ Customer 和 appGetCustomer ——我想这是可读性的问题。
  • 大量 sprocs 集合可以分为 Oracle 包、 ManagementStudio (SQLServer)解决方案和项目或 SQLServer 架构。
  • 应该避免使用难以理解的缩写。

为什么我选择这个答案: 有那么多好的回答。谢谢大家！如你所见，很难只选一个。我选择的那个与我产生了共鸣。我遵循了他描述的相同路径——尝试使用 Verb + Noun，然后找不到适用于 Customer 的所有 sprocs。

能够定位现有的 sproc，或者确定它是否存在，是非常重要的。如果有人不小心用另一个名称创建了一个重复的 spproc，就会产生严重的问题。

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

他还提倡使用应用程序名作为前缀，而不是不太有用的 usp _。正如一些人指出的那样，有时数据库包含用于多个应用程序的 sprocs。因此，应用程序名称前缀有助于隔离 sproc AND，从而帮助 DBA 和其他人确定 sproc 用于哪个应用程序。

84196 次浏览
小开

我总是在 包裹中封装存储过程(我在工作中使用 Oracle)。这将减少单独对象的数量，并有助于代码重用。

变数命名原则是一个品味的问题，在项目开始阶段，你应该与所有其他开发人员保持一致。

小开

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

对于较大的数据库，添加一个模式或子系统名称，例如 Receiving、 Purchase 等，以便将它们分组在一起(因为 sql server 喜欢按字母顺序显示它们)

为了清晰起见，我尽量避免在名称中使用缩写(项目中的新人不必想知道‘ UNAICFE’代表什么，因为 sproc 的名称是 uspUsingNoAbbreationsIncreasesClarityForEvery)

小开

我认为 usp 的变数命名原则对谁都没有好处。

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

小开

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

如果我们没有遗留约束，我非常肯定我们不会使用前缀。

在前缀之后，我们通常以一个动词开始 SP 名称，该动词描述过程的操作，然后是我们操作的实体的名称。允许实体名称的多元化——我们试图强调可读性，这样就可以很明显地看出过程仅仅从名称就可以做什么。

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

shopGetCategories
shopUpdateItem
小开

系统匈牙利 (就像上面的“ usp”前缀)让我不寒而栗。

我们在不同的、结构类似的数据库之间共享许多存储过程，因此对于特定于数据库的数据库，我们使用数据库名称本身的前缀; 共享过程没有前缀。我认为使用不同的模式可能是一种替代方法，可以完全去除这种有点难看的前缀。

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

回应蚂蚁金服的评论:

  1. 表和视图之间的区别与设计数据库模式的人员有关，而与访问或修改其内容的人员无关。在需要模式特定性的罕见情况下，很容易找到。对于随意的 SELECT 查询，它是不相关的。事实上，我认为能够同样对待表和视图是一个很大的优势。
  2. 与函数和存储过程不同，表或视图的名称不太可能以动词开头，也不太可能以一个或多个名词开头。
  3. 函数需要调用架构前缀。实际上，函数和存储过程之间的调用语法(无论如何我们使用的)是非常不同的。即使不是，也和1一样。将应用: 如果我可以将函数和存储过程一视同仁，为什么不呢？
小开

我不认为你的前缀是什么真的很重要，只要你是合乎逻辑和一致的。我个人使用

Spu _ [操作描述][过程描述]

其中操作描述是一个小范围的典型操作，如获取、设置、归档、插入、删除等。例如，流程描述比较简短，但是是描述性的

spu_archiveCollectionData

或者

spu_setAwardStatus

我以类似的方式命名函数，但前缀为 udf _

我见过有人试图使用伪匈牙利符号来命名过程，我认为这种方法隐藏的东西比它揭示的东西要多。只要我按字母顺序列出我的程序，我就能看到它们按功能分组，那么对我来说，这似乎就是顺序和不必要的严格之间的最佳位置

小开

使用 sp_启动存储过程名称在 SQLServer 中是不好的，因为系统 sprocs 都以 sp _ 开始。一致的命名(甚至在大地精的范围内)是有用的，因为它促进了基于数据字典的自动化任务。前缀在 SQLServer2005中的用处稍微小一些，因为它支持模式，模式可以用于各种类型的名称空间，就像以前在名称上使用前缀一样。例如，在星型模式中，可以使用 暗淡和 事实模式，并按照此约定引用表。

对于存储过程，前缀有助于从系统 sprocs 中识别应用程序 sprocs。与 sp_相比，up_使得从数据字典中识别非系统存储过程变得相对容易。

小开
最佳答案

对于我的上一个项目，我使用 usp _ [ Action ][ Object ][ Process ] ，例如 usp _ AddProduct 或 usp _ GetProductList，usp _ GetProductDetails。然而现在的数据库有700多个过程，要在一个特定的对象上找到所有过程变得更加困难。例如，我现在必须搜索50多个产品添加添加过程，50多个获取等。

因为这个原因，在我的新应用程序中，我打算按对象分组过程名称，我也删除了 usp，因为我觉得它有点多余，除了告诉我它是一个过程，我可以从过程本身的名称中推断出来。

新格式如下

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


App_Tags_AddTag
App_Tags_AddTagRelations
App_Product_Add
App_Product_GetList
App_Product_GetSingle

它有助于对事物进行分组，以便以后更容易地查找，特别是在有大量 sprocs 的情况下。

关于使用多个对象的地方，我发现大多数实例都有一个主对象和辅助对象，因此主对象在普通实例中使用，辅助对象在流程部分中引用，例如 App _ Product _ AddAttribute。

小开

我总是用:

Usp [表名][操作][附加细节]

给定一个名为“ tblUser”的表，我得到:

  • UspUserCreate
  • UspUserSelect
  • UspUserSelectByNetworkID

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

在 SQLServerIDE 中的编辑器与 VisualStudio 一样好之前，我将保留前缀。

小开

在 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 可能使用多个表，这对它没有帮助。

如果程序执行的函数比单个名称所能处理的函数多，这意味着您的程序执行的函数远远超出了必要的范围，并且需要再次分割它们。

希望能帮上忙。

小开

以下是关于 SQLServer 中 sp _ prefix 问题的一些说明。

以前缀 sp _ are 系统 sprocs 命名的存储过程存储在 Master 数据库中。

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

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

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

下面是 Ant 在评论中提供的另一个有用的资源。

小开

涉及到的数据库对象的应用程序前缀 _ 操作前缀 _ 描述。

我们使用的操作前缀-

  • “ 走开”-返回一个记录集
  • “ 在”-插入数据
  • “ Upd”-更新数据
  • “ Del”-删除数据

例如:

Wmt _ ins _ customer _ Details

劳动力管理工具，在客户表中插入详细信息

优势

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

这个系统对我们来说工作得很好，在一个数据库中有大约1000个存储过程。

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

小开

这些年来，我几乎用过所有不同的系统。我终于开发出了这个，我现在仍在使用它:

前缀:

  • 大部分是 CRUD
  • Rpt-Report: 不言自明
  • Tsk-Task: 通常具有过程逻辑，通过计划作业运行

行动说明:

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

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

目标:

对于 gen (CRUD) ，这是受影响的表或视图名。对于 rpt (Report) ，这是报告的简短描述。对于 tsk (Task) ，这是对任务的简短描述。

可选澄清器:

这些都是可选的信息位，用于加强对过程的理解。例如“ By”，“ For”等。

格式:

[前缀][操作说明符][实体][可选澄清符]

过程名称示例:

genInsOrderHeader


genSelCustomerByCustomerID
genSelCustomersBySaleDate


genUpdCommentText


genDelOrderDetailLine


rptSelCustomersByState
rptSelPaymentsByYear


tskQueueAccountsForCollection
小开

我目前使用的格式如下

注释:

[前缀] [申请书][模块] _ [名称]

例如:

P _ CMS _ USER _ UserInfoGet

我喜欢这个符号有几个原因:

  • 从非常简单的 Prefix 开始，只需编写代码来执行以前缀开头的对象(例如，为了减少 SQL 注入)
  • 在我们更大的环境中，多个团队在运行相同数据库架构的不同应用程序上工作。Application 符号指定哪个组拥有 SP。
  • 模块和名称部分简单地完成了层次结构。所有的名称应该能够匹配的组/应用程序，模块，功能从层次结构。
小开

基于@ID 获取 XXX

得到所有 XXX-得到所有 XXX

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

DelXXX-基于@ID 删除 XXX

小开

TableName _ WhatItDo

  • 注释 _ GetByID

  • 顾客名单

  • UserPreferences _ DeleteByUserID

没有前缀，没有愚蠢的匈牙利废话。只有与它关系最密切的表的名称，以及对它的功能的快速描述。

上面的一个警告: 我个人总是在所有自动生成的 CRUD 前面加上 zCRUD _ 的前缀，这样它就可以排序到列表的末尾，我就不必看它了。

小开

我加入的比较晚，但是我想在这里回复:

在我最近的两个项目中，有不同的趋势，比如我们使用的一个项目:

获取数据: s < tablename > & # 95; G
删除数据: s < tablename > & # 95; D
要插入 Data: s < tablename > & # 95; I
更新数据: s < tablename > & # 95; U < br/>

这种命名约定也遵循前端前缀的单词 DT。

例如:

exec sMedicationInfo_G
exec sMedicationInfo_D
exec sMedicationInfo_I
exec sMedicationInfo_U

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

而在第二个项目中，我们使用了相同的命名约定，只是略有不同:

获取数据: sp & # 95; < tablename > G
删除数据: sp & # 95; < tablename > D
要插入 Data: sp & # 95; < tablename > I
更新数据: sp & # 95; < tablename > U

例如:

exec sp_MedicationInfoG
exec sp_MedicationInfoD
exec sp_MedicationInfoI
exec sp_MedicationInfoU

提交答案