Naming conventions for SQL Server stored procedures


By:
Overview

One good thing to do for all of your SQL Server objects is to come up with a naming convention to use.  There are not any hard and fast rules, so this is really just a guideline on what should be done.

Explanation

SQL Server uses object names and schema names to find a particular object that it needs to work with.  This could be a table, stored procedure, function ,etc...

It is a good practice to come up with a standard naming convention for you objects including stored procedures.


Do not use sp_ as a prefix

One of the things you do not want to use as a standard is "sp_".  This is a standard naming convention that is used in the master database.  If you do not specify the database where the object is, SQL Server will first search the master database to see if the object exists there and then it will search the user database. So avoid using this as a naming convention.


Standardize on a Prefix

It is a good idea to come up with a standard prefix to use for your stored procedures.  As mentioned above do not use "sp_", so here are some other options.

  • usp_
  • sp
  • usp
  • etc...

To be honest it does not really matter what you use.  SQL Server will figure out that it is a stored procedure, but it is helpful to differentiate the objects, so it is easier to manage.

So a few examples could be:

  • spInsertPerson
  • uspInsertPerson
  • usp_InsertPerson
  • InsertPerson

Again this is totally up to you, but some standard is better than none.


Naming Stored Procedure Action

I liked to first give the action that the stored procedure takes and then give it a name representing the object it will affect.

So based on the actions that you may take with a stored procedure, you may use:

  • Insert
  • Delete
  • Update
  • Select
  • Get
  • Validate
  • etc...

So here are a few examples:

  • uspInsertPerson
  • uspGetPerson
  • spValidatePerson
  • SelectPerson
  • etc...

Another option is to put the object name first and the action second, this way all of the stored procedures for an object will be together.

  • uspPersonInsert
  • uspPersonDelete
  • uspPersonGet
  • etc...

Again, this does not really matter what action words that you use, but this will be helpful to classify the behavior characteristics.


Naming Stored Procedure Object

The last part of this is the object that you are working with.  Some of these may be real objects like tables, but others may be business processes.  Keep the names simple, but meaningful.  As your database grows and you add more and more objects you will be glad that you created some standards.

So some of these may be:

  • uspInsertPerson - insert a new person record
  • uspGetAccountBalance - get the balance of an account
  • uspGetOrderHistory - return list of orders

Schema Names

Another thing to consider is the schema that you will use when saving the objects.  A schema is the a collection of objects, so basically just a container.  This is useful if you want to keep all utility like objects together or have some objects that are HR related, etc...

This logical grouping will help you differentiate the objects further and allow you to focus on a group of objects.

Here are some examples of using a schema:

  • HR.uspGetPerson
  • HR.uspInsertPerson
  • UTIL.uspGet
  • UTIL.uspGetLastBackupDate
  • etc...

To create a new schema you use the CREATE SCHEMA command

Here is a simple example to create a new schema called "HR" and giving authorization to this schema to "DBO".

CREATE SCHEMA [HumanResources] AUTHORIZATION [dbo]

Putting It All Together

So you basically have four parts that you should consider when you come up with a naming convention:

  • Schema
  • Prefix
  • Action
  • Object

Take the time to think through what makes the most sense and try to stick to your conventions.


Last Update: 3/24/2009




Comments For This Article




Friday, November 1, 2024 - 11:29:26 AM - Mario Back To Top (92611)
Tip Comments Pending Approval

Tuesday, February 13, 2018 - 10:19:31 AM - Greg Robidoux Back To Top (75200)

Hi Tom,

I agree that using prefixes is an old holdover from earlier SQL Server days.  I agree with you that the object name should identify the purpose of the object without the need to use a prefix.

Whatever approach is taken, hopefully the name of the object can identify its purpose without having to do a lot of research of the objects contents.

-Greg


Tuesday, February 13, 2018 - 10:13:13 AM - Tom Back To Top (75198)

I heartily disagree with the whole idea of an object prefix. If you're calling a stored procedure then you should know that it's a stored procedure without it being named "usp*". It's hard to come up with any situation where the prefix adds anything other than making your code read less naturally.


Thursday, May 4, 2017 - 7:00:08 AM - Nandini Back To Top (55433)

 good.

 


Tuesday, November 15, 2016 - 4:23:43 PM - Greg Robidoux Back To Top (43769)

Hi Gabe, most of the articles have a date at the bottom, but the tutorials don't.  This was written in 2009, but everything should still appy. 

Here is an article on the sp_ naming convention which talks about changes in SQL 2012.  https://sqlperformance.com/2012/10/t-sql-queries/sp_prefix 

Thanks
Greg


Tuesday, November 15, 2016 - 3:53:57 PM - Gabe Back To Top (43768)

 No offense, but I can't take undated tech articles seriously.  How old is this?  If this was written for SQL 7.0, 2000, or even 2005, is the "sp_" comment still relevant?

 















get free sql tips
agree to terms