首页
学习
活动
专区
工具
TVP
发布
社区首页 >问答首页 >您对存储过程的命名约定是什么?

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

Stack Overflow用户
提问于 2008-10-26 17:03:43
回答 15查看 80.1K关注 0票数 128

我见过各种命名存储过程的规则。

有些人用usp_作为存储过程名称的前缀,有些人用应用程序名称的缩写作为前缀,还有一些人用所有者名称作为前缀。您不应该在SQL Server中使用sp_,除非您是认真的。

有些proc名称以动词开头(Get、Add、Save、Remove)。其他人则强调实体名称。

在包含数百个存储过程的数据库中,当您认为存储过程已经存在时,可能很难滚动并找到合适的存储过程。命名约定可以更容易地定位存储过程。

您是否使用命名约定?请描述它,并解释为什么你更喜欢它而不是其他选择。

回复摘要:

  • 似乎每个人都提倡命名的一致性,对于每个人来说,使用相同的命名约定可能比使用哪个特定的used.
  • Prefixes:更重要,而许多人使用usp_或类似的东西(但很少使用sp_),许多人使用数据库或应用程序名称。一个聪明的数据库管理员使用gen、rpt和tsk来区分一般的CRUD sprocs和用于报告或任务的那些。
  • 动词+名词似乎比名词+动词更受欢迎。有些人对谓词使用SQL关键字(Select、Insert、Update、Delete),而另一些人则使用非SQL谓词(或它们的缩写),如Get和Add。有些人区分单数和复数名词,以表示检索的是一个还是多个记录。
  • 在适当的地方建议在末尾加上一个短语。GetCustomerBySaleDate.
  • Some,GetCustomerById人们在名字段之间使用下划线,有些人避免使用下划线。SQLServervs.SQLServersProc --我认为这是一个readability.
  • Large集合的问题,可以将其划分到app_包或Management Studio (SQL Get_Customer )解决方案和项目中,或者应该避免使用appGetCustomer的缩写。

我为什么选择我做的答案:有很多很好的回答。谢谢大家!正如您所看到的,很难只选择一个。我选择的那个引起了我的共鸣。我遵循了他描述的相同路径--尝试使用动词+名词,然后无法找到适用于客户的所有sprocs。

能够定位现有的存储过程,或者确定是否存在存储过程,这一点非常重要。如果有人无意中使用另一个名称创建了重复的存储过程,可能会出现严重的问题。

由于我通常在具有数百个sprocs的大型应用程序上工作,因此我倾向于使用最容易找到的命名方法。对于较小的应用程序,我可能建议使用动词+名词,因为它遵循方法名称的通用编码约定。

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

EN

回答 15

Stack Overflow用户

回答已采纳

发布于 2008-10-26 17:50:57

在我的上一个项目中,我使用了usp_ActionProcess,例如,usp_AddProduct或usp_GetProductList,usp_GetProductDetail。然而,现在的数据库是700多个过程,要找到一个特定对象上的所有过程变得困难得多。例如,我现在必须为Product add搜索50多个Add过程,为Get等搜索50多个add过程。

由于这一点,在我的新应用程序中,我计划按对象对过程名称进行分组,我还删除了usp,因为我觉得它有点多余,只是告诉我它是一个过程,这是我可以从过程本身的名称中扣除的东西。

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

App_Tags_AddTag
App_Tags_AddTagRelations
App_Product_Add 
App_Product_GetList
App_Product_GetSingle

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

关于使用多个对象的地方,我发现大多数实例都有主对象和次对象,因此主对象在普通实例中使用,而次对象在流程部分中引用,例如App_Product_AddAttribute。

票数 68
EN

Stack Overflow用户

发布于 2008-10-26 18:19:06

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

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

如果您为存储过程提供此前缀,SQL Server将首先在Master数据库中查找它们,然后在context数据库中查找它们,从而造成不必要的资源浪费。而且,如果用户创建的存储过程与系统存储过程同名,则不会执行用户创建的存储过程。

sp_前缀指示可以从所有数据库访问存储过程,但它应该在当前数据库的上下文中执行。

Here's提供了一个很好的解释,其中包括一个性能热门的演示。

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

票数 37
EN

Stack Overflow用户

发布于 2008-10-26 17:29:02

Systems Hungarian (就像上面的"usp“前缀)让我不寒而栗。

我们在结构相似的不同数据库之间共享许多存储过程,因此对于特定于数据库的数据库,我们使用数据库名称本身的前缀;共享过程没有前缀。我认为使用不同的模式可能是完全摆脱这种有点丑陋的前缀的另一种选择。

前缀后面的实际名称与函数命名几乎没有什么不同:通常是“添加”、“设置”、“生成”、“计算”、“删除”等动词,后面跟着几个更具体的名词,如"User“、"DailyRevenues”等。

回应Ant的评论:

  1. 表和视图之间的区别与设计数据库架构的人员相关,而与访问或修改其内容的人员无关。事实上,我认为能够将表和视图视为具有函数和存储过程的大模式,表或视图的名称不太可能以动词开头,或者只能是一个或多个名词。
  2. 函数需要调用advantage.
  3. Unlike前缀。实际上,函数和存储过程之间的调用语法(无论如何,我们使用的)是非常不同的。但是,即使它不是,与1一样。也适用:如果我可以将函数和存储过程同等对待,为什么不可以呢?
票数 16
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/238267

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档