¿Cuál es su convención de nomenclatura para los procedimientos almacenados? [cerrado]

Aquí hay algunas aclaraciones sobre el problema del prefijo sp_ en SQL Server.

Los procedimientos almacenados nombrados con el prefijo sp_ son sprocs del sistema almacenados en la base de datos Maestra.

Si le da a su sproc este prefijo, SQL Server los busca primero en la base de datos Maestra, luego en la base de datos contextual, desperdiciando así recursos innecesariamente. Y, si el sproc creado por el usuario tiene el mismo nombre que un sproc del sistema, el sproc creado por el usuario no se ejecutará.

El prefijo sp_ indica que el sproc es accesible desde todas las bases de datos, pero que debe ejecutarse en el contexto de la base de datos actual.

Aquí está una buena explicación, que incluye una demostración del éxito de rendimiento.

Aquí está otra fuente útil proporcionada por Ant en un comentario.

Systems Hungarian (como el prefijo "usp" anterior) me hace estremecer.

Compartimos muchos procedimientos almacenados en diferentes bases de datos de estructura similar, por lo que para las bases de datos específicas, usamos un prefijo del nombre de la base de datos en sí; los procedimientos compartidos no tienen prefijo. Supongo que el uso de diferentes esquemas podría ser una alternativa para deshacerse de tales prefijos algo feos por completo.

El nombre real después del prefijo no es muy diferente del nombre de la función: típicamente a verbos como "Add", "Set", "Generate", "Calculate", "Delete", etc., seguido de varios sustantivos más específicos como "User", "DailyRevenues", y así sucesivamente.

Respondiendo al comentario de Ant:

1. La diferencia entre una tabla y una vista es relevante para aquellos que diseñan el esquema de la base de datos, no para aquellos que acceden o modifican su contenido. En el raro caso de necesitar detalles del esquema, es bastante fácil de encontrar. Para la consulta casual SELECT, es irrelevante. De hecho, considero que ser capaz de tratar las mesas y las vistas de la misma manera que una gran ventaja.
2. A diferencia de las funciones y procedimientos almacenados, es poco probable que el nombre de una tabla o vista comience con un verbo, o sea cualquier cosa menos uno o más sustantivos.
3. Una función requiere que se llame al prefijo del esquema. De hecho, la sintaxis de llamada (que usamos, de todos modos) es muy diferente entre una función y un procedimiento almacenado. Pero incluso si no lo fuera, lo mismo que 1. se aplicaría: si puedo tratar las funciones y los procedimientos almacenados de la misma manera, ¿por qué ¿no debería?

Iniciar un nombre de procedimiento almacenado consp_ es malo en SQL Server porque todos los sprocs del sistema comienzan con sp_. La nomenclatura consistente (incluso en la medida de hobgoblin-dom) es útil porque facilita tareas automatizadas basadas en el diccionario de datos. Los prefijos son un poco menos útiles en SQL Server 2005, ya que admite esquemas, que se pueden usar para varios tipos de espacios de nombres de la misma manera que los prefijos en los nombres. Por ejemplo, en un esquema star, uno podría tener dim y fact esquemas y véanse los cuadros del presente convenio.

Para los procedimientos almacenados, el prefijo es útil con el propósito de identificar sprocs de la aplicación de sprocs del sistema. up_ vs. sp_ hace que sea relativamente fácil identificar procedimientos no almacenados en el sistema desde el diccionario de datos.

TableName_WhatItDoes

• Comment_GetByID

• Customer_List

• UserPreference_DeleteByUserID

Sin prefijos ni tonterías húngaras. Solo el nombre de la tabla con la que está más estrechamente asociada, y una breve descripción de lo que hace.

Una advertencia a lo anterior: Personalmente siempre prefijo todo mi CRUD autogenerado con zCRUD_ para que se clasifique al final de la lista donde no tengo que mirar se.

He utilizado casi todos los diferentes sistemas a lo largo de los años. Finalmente desarrollé este, que continúo usando hoy:

Prefijo:

• gen - General: CRUD, mayormente
• rpt - Report: auto-explanatory
• tsk-Task: normalmente algo con lógica procedimental, se ejecuta mediante trabajos programados

Especificador de acción:

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

(En los casos en que el procedimiento hace muchas cosas, el objetivo general se utiliza para elegir el especificador de acción. Por ejemplo, un INSERTO de cliente puede requerir una buena cantidad de trabajo de preparación, pero el objetivo general es INSERTAR, por lo que se elige "Ins".

Objeto:

Para gen (CRUD), este es el nombre de la tabla o vista que se ve afectado. Para rpt (Informe), esta es la breve descripción del informe. Para tsk (Tarea) esta es la breve descripción de la tarea.

Clarificadores opcionales:

Estos son bits opcionales de información utilizados para mejorar la comprensión del procedimiento. Ejemplos incluyen " By", "Para", etc.

Formato:

[Prefijo] [Especificador de Acción] [Entidad] [Clarificadores opcionales]

Ejemplos de nombres de procedimientos:

genInsOrderHeader

genSelCustomerByCustomerID
genSelCustomersBySaleDate

genUpdCommentText

genDelOrderDetailLine

rptSelCustomersByState
rptSelPaymentsByYear

tskQueueAccountsForCollection

Siempre encapsulo los procedimientos almacenados en paquetes (estoy usando Oracle, en el trabajo). Esto reducirá el número de objetos separados y ayudará a reutilizar el código.

La convención de nomenclatura es una cuestión de gustos y algo que debe estar de acuerdo con todos los demás desarrolladores al inicio del proyecto.

Para bases de datos pequeñas, utilizo uspTableNameOperationName, por ejemplo, uspCustomerCreate, uspCustomerDelete, etc. Esto facilita la agrupación por entidad "principal".

Para bases de datos más grandes, agregue un nombre de esquema o subsistema, por ejemplo, Recepción, compra, etc. para mantenerlos agrupados (ya que a sql server le gusta mostrarlos alfabéticamente)

Trato de evitar abreviaturas en los nombres, para mayor claridad (y las personas nuevas en el proyecto no tienen que preguntarse qué significa 'UNAICFE' porque el sproc se denomina uspUsingNoAbbreviationsIncreasesclarityforeveryone)

Actualmente uso un formato que es como el siguiente

Notación:

[PREFIJO][APLICACIÓN][MÓDULO]_[NOMBRE]

Ejemplo:

P_CMS_USER_UserInfoGet

Me gusta esta notación por algunas razones:

• comenzando con Prefijo muy simple permite escribir código para ejecutar solo objetos que comienzan con el prefijo (para reducir la inyección SQL, por ejemplo)
• en nuestro entorno más amplio, varios equipos están trabajando en diferentes aplicaciones que se ejecutan de la misma arquitectura de base de datos. La notación de aplicación designa qué grupo posee el SP.
• Las secciones Módulo y Nombre simplemente completan la jerarquía. Todos los nombres deben ser capaces de ser emparejados a Grupo / Aplicación, Módulo, Función de la heirarchy.

Siempre uso:

Usp [Nombre de la tabla] [Acción] [Detalle adicional]

Dada una tabla llamada "tblUser", eso me da:

• uspUserCreate
• uspUserSelect
• uspUserSelectByNetworkID

Los procedimientos están ordenados alfabéticamente por nombre de tabla y por funcionalidad, por lo que es fácil ver lo que puedo hacer con cualquier tabla dada. El uso del prefijo " usp " me permite saber a qué estoy llamando si estoy (por ejemplo) escribiendo un procedimiento de 1000 líneas que interactúa con otros procedimientos, múltiples tablas, funciones, vistas y servidores.

Hasta que el editor en el IDE de SQL Server sea tan bueno como Visual Studio, conservaré los prefijos.

Application prefix_ operation prefix_ description of database objects involved (minus the spaces between underscores - had to put spaces in for them to appear).

Prefijos de operación que usamos -

• "get" – devuelve un conjunto de registros
• "ins " - inserta datos
• "upd " - actualiza los datos
• "del " - elimina datos

por ejemplo

Wmt_ ins _ cliente _detalles

"herramienta de gestión de personal, insertar detalles en la tabla de clientes"

Ventajas

Todos los procedimientos almacenados relacionados con la misma aplicación se agrupan por nombre. Dentro del grupo, los procedimientos almacenados que llevan a cabo el mismo tipo de operación (por ejemplo, inserciones, actualizaciones, etc.) se agrupan.

Este sistema funciona bien para nosotros, teniendo aprox. 1000 procedimientos almacenados en una base de datos de la parte superior de mi cabeza.

No han venido a través de las desventajas de este enfoque hasta el momento.

GetXXX-Obtiene XXX basado en @ID

GetAllXXX-Obtiene todo XXX

PutXXX-Inserta XXX si se pasa @ID es -1; de lo contrario se actualiza

DelXXX-Elimina XXX basado en @ID

Creo que la convención de nomenclatura usp_ no hace ningún bien a nadie.

En el pasado, he utilizado los prefijos Get/Update/Insert/Delete para las operaciones CRUD, pero ahora, desde que uso Linq para SQL o EF para hacer la mayor parte de mi trabajo CRUD, estos se han ido por completo. Dado que tengo tan pocos procs almacenados en mis nuevas aplicaciones, las convenciones de nomenclatura ya no importan como solían hacerlo; -)

Para la aplicación actual en la que estoy trabajando, tenemos un prefijo que identifica el nombre de la aplicación (cuatro letras minúsculas). La razón de esto es que nuestra aplicación debe ser capaz de coexistir con una aplicación heredada en la misma base de datos, por lo que el prefijo es una necesidad.

Si no tuviéramos la restricción legacy, estoy bastante seguro de que no estaríamos usando un prefijo.

Después del prefijo, generalmente comenzamos el nombre SP con un verbo que describe lo que hace el procedimiento, y luego el nombre de la entidad en la que operamos. Se permite la pluralización del nombre de la entidad - Tratamos de enfatizar la legibilidad, para que sea obvio lo que hace el procedimiento solo desde el nombre.

Los nombres típicos de procedimientos almacenados en nuestro equipo serían:

shopGetCategories
shopUpdateItem

No creo que realmente importe exactamente cuál es tu prefijo, siempre y cuando seas lógico y consistente. Personalmente utilizo

Spu_ [descripción de la acción] [descripción del proceso]

Donde la descripción de la acción es una de una pequeña gama de acciones típicas como get, set, archive, insert, delete, etc. La descripción del proceso es algo corto pero descriptivo, por ejemplo

spu_archiveCollectionData 

O

spu_setAwardStatus

Nombro mis funciones de manera similar, pero con el prefijo udf_

He visto la gente intenta usar la notación pseudo-húngara para nombrar procedimientos, lo que en mi opinión oculta más de lo que revela. Siempre que cuando enumere mis procedimientos alfabéticamente puedo verlos agrupados por funcionalidad, entonces para mí ese parece ser el punto dulce entre el orden y el rigor innecesario

Evite sp_* en SQl server porque todos los prcedures almacenados en el sistema comienzan con sp_ y, por lo tanto, se hace más difícil para el sistema encontrar el objeto correspondiente al nombre.

Así que si comienzas con algo que no sea sp_ las cosas se vuelven más fáciles.

Así que usamos un nombre común de Proc_ para empezar. Esto hace que sea más fácil identificar los procedimientos si se presentan con un archivo de esquema grande.

Aparte de eso asignamos un prefijo que identifica la función. Como

Proc_Poll_Interface, Proc_Inv_Interface etc.

Esto nos permite encontrar todos los procs almacenados que hacen el trabajo de ENCUESTA vs que hace Inventario, etc.

De todos modos, el sistema de prefijos depende del dominio del problema. Pero al dijo y hizo algo similar debería estar presente, incluso si es solo para permitir que la gente quicly localizar el procedimiento almacenado en el explorador desplegable para la edición.

Otros eg de función.

Proc_Order_Place
Proc_order_Delete
Proc_Order_Retrieve
Proc_Order_History

Seguimos el nombre basado en funciones porque los Procs son similares al código / función en lugar de objetos estáticos como tablas. No ayuda que Procs pueda trabajar con más de una tabla.

Si el proc realizó más funciones de las que se pueden manejar en un solo nombre, significa que su proc está haciendo mucho más de lo necesario y es hora de dividirlas nuevamente.

Espero que eso ayude.

Me uní tarde al hilo, pero quiero ingresar mi respuesta aquí:

En mis dos últimos proyectos hay diferentes tendencias como, en uno que utilizamos:

Para obtener Datos: s _G
Para eliminar Datos: s _D
Para insertar Datos: s _I
Para actualizar los Datos: s _U

Estas convenciones de nomenclatura también se siguen en el front-end prefijando la palabra dt.

Ejemplo:

exec sMedicationInfo_G
exec sMedicationInfo_D
exec sMedicationInfo_I
exec sMedicationInfo_U

Con la ayuda de las convenciones de nombres anteriores en nuestra aplicación tenemos un nombre bueno y fácil de recordar.

Mientras que en el segundo proyecto utilizamos las mismas convenciones de nomenclatura con diferencia de lill:

Para obtener Datos: sp_ G
Para eliminar Datos: sp_ D
Para insertar Datos: sp_ I
Para actualizar los Datos: sp_ U

Ejemplo:

exec sp_MedicationInfoG
exec sp_MedicationInfoD
exec sp_MedicationInfoI
exec sp_MedicationInfoU