What is your naming convention for stored procedures? [closed]

Answer 1

I joined late the thread but I want to enter my reply here:

In my last two projects there are different trends like, in one we used:

To get Data : s<tablename>_G
To delete Data : s<tablename>_D
To insert Data : s<tablename>_I
To update Data : s<tablename>_U

This naming conventions is also followed in front-end by prefixing the word dt.

Example:

exec sMedicationInfo_G
exec sMedicationInfo_D
exec sMedicationInfo_I
exec sMedicationInfo_U

With the help of above naming conventions in our application we have a good and easy to remember names.

While in second project we used the same naming conventions with lill difference:

To get Data : sp_<tablename>G
To delete Data : sp_<tablename>D
To insert Data : sp_<tablename>I
To update Data : sp_<tablename>U

Example:

exec sp_MedicationInfoG
exec sp_MedicationInfoD
exec sp_MedicationInfoI
exec sp_MedicationInfoU

Answer 2

I always encapsulate the stored procedures in packages (I'm using Oracle, at work). That will reduce the number of separate objects and help code reuse.

The naming convention is a matter of taste and something you should agree with all the other developers at project start.

Answer 3

For my last project i used usp_[Action][Object][Process] so for example, usp_AddProduct or usp_GetProductList, usp_GetProductDetail. However now the database is at 700 procedures plus, it becomes a lot harder to find all procedures on a specific object. For example i now have to search 50 odd Add procedures for the Product add, and 50 odd for the Get etc.

Because of this in my new application I'm planning on grouping procedure names by object, I'm also dropping the usp as I feel it is somewhat redundant, other than to tell me its a procedure, something I can deduct from the name of the procedure itself.

The new format is as follows

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

App_Tags_AddTag
App_Tags_AddTagRelations
App_Product_Add 
App_Product_GetList
App_Product_GetSingle

It helps to group things for easier finding later, especially if there are a large amount of sprocs.

Regarding where more than one object is used, I find that most instances have a primary and secondary object, so the primary object is used in the normal instance, and the secondary is refered to in the process section, for example App_Product_AddAttribute.

Answer 4

I think the usp_ naming convention does nobody any good.

In the past, I've used Get/Update/Insert/Delete prefixes for CRUD operations, but now since I use Linq to SQL or the EF to do most of my CRUD work, these are entirely gone. Since I have so few stored procs in my new applications, the naming conventions no longer matter like they used to ;-)

Answer 5

I always use:

usp[Table Name][Action][Extra Detail]

Given a table called "tblUser", that gives me:

• uspUserCreate
• uspUserSelect
• uspUserSelectByNetworkID

The procedures are alphabetically sorted by table name and by functionality, so it's easy to see what I can do to any given table. Using the prefix "usp" lets me know what I'm calling if I'm (for example) writing a 1000-line procedure that interacts with other procedures, multiple tables, functions, views and servers.

Until the editor in the SQL Server IDE is as good as Visual Studio I'm keeping the prefixes.

Answer 6

I don't think it really matters precisely what your prefix is so long as you're logical and consistent. Personally I use

spu_[action description][process description]

where action description is one of a small range of typical actions such as get, set, archive, insert, delete etc. The process description is something short but descriptive, for example

spu_archiveCollectionData 

or

spu_setAwardStatus

I name my functions similarly, but prefix with udf_

I have seen people attempt to use pseudo-Hungarian notation for procedure naming, which in my opinion hides more than it reveals. So long as when I list my procedures alphabetically I can see them grouped by functionality then for me that seems to be the sweet spot between order and unnecessary rigour