What's the best practice of naming stored procedure for t-sql?

Question

I have worked with several big databases and the names of stored procedures were very different:

SP_PrefixXXX
PrefixYyyXxx
Prefix: Rep, Act

Answer 1

This may help. As I am front/backend programmer, I use the following for both MySQL and SQLServer:

SPx_PAGE/MODULE_ACTION_OBJECT 

x: R for read, I for insert, U for update, W for write (combines insert if index not exists or update if exists) and D for delete.

page/module: the place who calls the procedure

Examples:

SPR_DASHBOARD_GET_USERS //reads users data
SPW_COMPANIES_PUT_COMPANY //creates or modifies a company

Answer 2

Better create schema for seperate module.

Then Give Meaningful and simple name.

For Example: if you are working school project.

create Student schema

procedure name :AddStudent

So it will look like Student.AddStudent in procedurelist

same thing for Teacher Module

Answer 3

Im not a pro but i like this way

Prefix of application = XY; View = v; Stored Procedure = p; Function = f

Table: XY_Name
View: vXY_Name
Procedure: sXY_Name
Function: fXY_Name

What do you think ? I know some people use the two characters for identifying object type but one character is enough for most cases, right ?

Answer 4

Well, prefixing the name with "SP_" is pretty much redundant: it's naming for the implementation (it's an SP, as opposed to a table or a view). There are plenty of other ways (systebales, information_schema, how you use it) that will tell you hw it's implemented.

Instead you should name it for its interface, for what it does for you. For convenience (as many things end up ordered alphabetically), I like to group like things under like names, possibly using the same prefix.

But again, name it for what it does, not how it happens to be implemented.

In general, I find that the common naming conventions for database objects use underscores instead of CamelCase; this is just a matter of convention. What is not mere convention is the also common convention of using all lowercase letters for database objects; this allows you to ignore server settings which may or may not be case-insensitive.