sql - stored - ¿Cuál es su convención de nombres para los procedimientos almacenados?

procedimientos almacenados sql (17)

Actualmente uso un formato que es como el siguiente

Notación:

[PREFIX] [APPLICATION] [MODULE] _ [NAME]

Ejemplo:

P_CMS_USER_UserInfoGet

Me gusta esta notación por algunas razones:

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

He visto varias reglas para nombrar procedimientos almacenados.

Algunas personas prefijan el nombre de sproc con usp_, otros con una abreviatura para el nombre de la aplicación y otros con el nombre del propietario. No debería usar sp_ en SQL Server a menos que realmente lo diga en serio.

Algunos inician el nombre del proceso con un verbo (Obtener, Agregar, Guardar, Eliminar). Otros enfatizan el (los) nombre (s) de la entidad.

En una base de datos con cientos de sprocs, puede ser muy difícil desplazarse y encontrar un sproc adecuado cuando crees que ya existe uno. Las convenciones de nomenclatura pueden facilitar la localización de un sproc.

¿Utiliza una convención de nombres? Por favor, descríbalo y explica por qué lo prefieres sobre otras opciones.

Resumen de respuestas:

Todo el mundo parece abogar por la coherencia de los nombres, que podría ser más importante para todos usar la misma convención de nomenclatura de la que se utiliza en particular.
Prefijos: mientras que mucha gente usa usp_ o algo similar (pero rara vez sp_), muchos otros usan la base de datos o el nombre de la aplicación. Un DBA inteligente usa gen, rpt y tsk para distinguir los sprocs generales de CRUD de los usados para informes o tareas.
Verb + Sustantivo parece ser un poco más popular que Noun + Verb. Algunas personas usan las palabras clave SQL (Seleccionar, Insertar, Actualizar, Eliminar) para los verbos, mientras que otras usan verbos que no son SQL (o abreviaturas para ellos) como Obtener y Agregar. Algunos distinguen entre sustantivos singluar y plural para indicar si se recuperan uno o muchos registros.
Al final se sugiere una frase adicional, cuando corresponda. GetCustomerById, GetCustomerBySaleDate.
Algunas personas usan guiones bajos entre los segmentos de nombre, y algunas evitan los guiones bajos. app_ Get_Customer vs. appGetCustomer - Supongo que es cuestión de legibilidad.
Las grandes colecciones de sprocs se pueden segregar en paquetes de Oracle o proyectos y soluciones de Management Studio (SQL Server) o esquemas de SQL Server.
Abreviaciones inescrutables deben ser evitadas.

Por qué elegí la respuesta que hice: hay TANTAS buenas respuestas. ¡Gracias a todos! Como puede ver, sería muy difícil elegir solo uno. El que elegí resonó conmigo. He seguido el mismo camino que él describe, tratando de usar Verb + Sustantivo y luego no ser capaz de encontrar todos los sprocs que se aplican al Cliente.

Ser capaz de localizar un sproc existente, o determinar si alguno existe, es muy importante. Pueden surgir problemas graves si alguien inadvertidamente crea un sproc duplicado con otro nombre.

Como generalmente trabajo en aplicaciones muy grandes con cientos de sprocs, prefiero el método de nombres más fácil de encontrar. Para una aplicación más pequeña, podría recomendar Verb + Sustantivo, ya que sigue la convención de codificación general para nombres de métodos.

También aboga por el prefijo con el nombre de la aplicación en lugar de usp_ no muy útil. Como señalaron varias personas, a veces la base de datos contiene sprocs para múltiples aplicaciones. Por lo tanto, prefijar con el nombre de la aplicación ayuda a segregar los sprocs Y ayuda a los DBA y a otros a determinar para qué aplicación se utiliza el sproc.

Creo que la convención de nombres usp no hace ningún bien a nadie.

En el pasado, he usado los prefijos Get / Update / Insert / Delete para las operaciones CRUD, pero ahora desde que utilizo Linq to SQL o el EF para hacer la mayor parte de mi trabajo CRUD, estos desaparecieron por completo. Como tengo tan pocos procesos almacenados en mis nuevas aplicaciones, las convenciones de nombres ya no importan como solían ;-)

Evite sp_ * en el servidor SQl ya que todos los procedimientos almacenados del sistema comienzan con sp_ y, por lo tanto, se vuelve más difícil para el sistema encontrar el objeto correspondiente al nombre.

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

Entonces, usamos una denominación común de Proc_ para comenzar. Eso hace que sea más fácil identificar los procedimientos si se presenta con un gran archivo de esquema.

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

Proc_Poll_Interface, Proc_Inv_Interface etc.

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

De todos modos, el sistema de prefijo depende del dominio de tu problema. Pero todo lo dicho y hecho debe estar presente, incluso si solo se trata de permitir que la gente ubique rápidamente el procedimiento almacenado en el menú desplegable de Explorere para editarlo.

otros por ejemplo de función.

Proc_Order_Place Proc_order_Delete Proc_Order_Retrieve Proc_Order_History

Seguimos la función basada en nombrar coz Procs son similares a código / función en lugar de objetos estáticos como tablas. No ayuda que los Procs funcionen con más de una tabla.

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

Espero que ayude.

GetXXX - Obtiene XXX basado en @ID

GetAllXXX - Obtiene todo XXX

PutXXX: inserta XXX si pasa @ID es -1; otras actualizaciones

DelXXX: elimina XXX según @ID

He usado prácticamente todos los diferentes sistemas a lo largo de los años. Finalmente desarrollé este, que sigo usando hoy:

Prefijo:

gen - General: CRUD, en su mayoría
rpt - Informe: autoexplicativo
tsk - Tarea: generalmente algo con lógica de procedimiento, ejecutada a través de trabajos programados

Especificador de acción:

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

(En los casos donde el procedimiento hace muchas cosas, el objetivo general se utiliza para elegir el especificador de acción. Por ejemplo, un cliente INSERT puede requerir una gran 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 de información opcionales utilizados para mejorar la comprensión del procedimiento. Los ejemplos incluyen "Por", "Para", etc.

Formato:

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

Ejemplos de nombres de procedimientos:

genInsOrderHeader genSelCustomerByCustomerID genSelCustomersBySaleDate genUpdCommentText genDelOrderDetailLine rptSelCustomersByState rptSelPaymentsByYear tskQueueAccountsForCollection

Iniciar un nombre de procedimiento almacenado con sp_ es malo en SQL Server porque el sistema lo inicia todo con sp_. La nomenclatura constante (incluso en la medida de hobgoblin-dom) es útil porque facilita las 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 utilizados. Por ejemplo, en un esquema en estrella, uno podría tener esquemas débiles y de hecho y referirse a las tablas según esta convención.

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

Me uní al final del hilo pero quiero ingresar mi respuesta aquí:

En mis dos últimos proyectos hay diferentes tendencias, en una usamos:

Para obtener datos: s <tablename> _G
Para eliminar datos: s <tablename> _D
Para insertar datos: s <tablename> _I
Para actualizar los datos: s <tablename> _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 nombres buenos y fáciles de recordar.

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

Para obtener datos: sp_ <tablename> G
Para eliminar datos: sp_ <tablename> D
Para insertar datos: sp_ <tablename> I
Para actualizar los datos: sp_ <tablename> U

Ejemplo:

exec sp_MedicationInfoG exec sp_MedicationInfoD exec sp_MedicationInfoI exec sp_MedicationInfoU

No creo que realmente importe con precisión cuál es tu prefijo, siempre que seas lógico y consistente. Personalmente uso

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

donde la descripción de acción es una de una pequeña gama de acciones típicas, como obtener, establecer, archivar, insertar, eliminar, etc. La descripción del proceso es algo breve pero descriptiva, por ejemplo

spu_archiveCollectionData

spu_setAwardStatus

Nombro mis funciones de manera similar, pero prefijo con udf_

He visto a personas intentar usar notación pseudohúngara para nombrar procedimientos, lo que en mi opinión oculta más de lo que revela. Siempre y cuando enumere mis procedimientos alfabéticamente, puedo verlos agrupados por funcionalidad, entonces para mí, que parece ser el punto ideal entre el orden y el rigor innecesario

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 obligatorio.

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

Después del prefijo usualmente comenzamos el nombre del 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. Intentamos enfatizar la legibilidad, de modo que es obvio qué hace el procedimiento solo con el nombre.

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

shopGetCategories shopUpdateItem

Para mi último proyecto usé usp_ [Action] [Object] [Process], por ejemplo, usp_AddProduct o usp_GetProductList, usp_GetProductDetail. Sin embargo, ahora la base de datos tiene 700 procedimientos más, se vuelve mucho más difícil encontrar todos los procedimientos en un objeto específico. Por ejemplo, ahora tengo que buscar 50 procedimientos de Agregar impar para el Producto agregado, y 50 impar para el Obtener, etc.

Debido a esto en mi nueva aplicación estoy planeando agrupar nombres de procedimientos por objeto, también estoy descartando el usp porque siento que es algo redundante, aparte de decirme que es un procedimiento, algo que puedo deducir del nombre de el procedimiento en sí.

El nuevo formato es el siguiente

[App]_[Object]_[Action][Process] App_Tags_AddTag App_Tags_AddTagRelations App_Product_Add App_Product_GetList App_Product_GetSingle

Ayuda a agrupar cosas para encontrarlas más tarde, especialmente si hay una gran cantidad de sprocs.

En cuanto a dónde se usa más de un objeto, encuentro que la mayoría de las instancias tienen un objeto primario y secundario, por lo que el objeto primario se usa en la instancia normal y el secundario en la sección de proceso, por ejemplo App_Product_AddAttribute.

Siempre encapsulo los procedimientos almacenados en paquetes (estoy usando Oracle, en el trabajo). Eso reducirá la cantidad de objetos separados y ayudará a reutilizar los códigos.

La convención de nomenclatura es una cuestión de gusto y algo con lo que deberías estar de acuerdo con todos los demás desarrolladores al inicio del proyecto.

Yo siempre uso:

usp [Nombre de 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 qué puedo hacer con cualquier tabla. Usar el prefijo "usp" me permite saber a qué llamo 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 SQL Server IDE sea tan bueno como Visual Studio, guardo los prefijos.

aplicación prefix_ operación prefix_ descripción de los objetos de base de datos implicados (menos los espacios entre guiones bajos - tuvo que poner espacios para que aparezcan) .

prefijos de operación que usamos -

" Get " - devuelve un conjunto de registros
" Ins " - inserta datos
" Upd " - actualiza datos
" Del " - borra datos

p.ej

wmt_ ins _ customer _details

"herramienta de gestión de personal, inserte 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 en la parte superior de mi cabeza.

No he encontrado ninguna desventaja en este enfoque hasta el momento.

para bases de datos pequeñas, uso 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, Compras, etc. para mantenerlos agrupados (ya que al servidor SQL le gusta mostrarlos alfabéticamente)

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

Los sistemas húngaros (como el prefijo "usp" anterior) me hacen estremecer.

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

El nombre real después del prefijo apenas difiere del nombre de la función: típicamente un verbo como "Agregar", "Establecer", "Generar", "Calcular", "Eliminar", etc., seguido de varios nombres más específicos como "Usuario". "," DailyRevenues ", y así sucesivamente.

Respondiendo al comentario de Ant:

La diferencia entre una tabla y una vista es relevante para quienes diseñan el esquema de la base de datos, no para quienes acceden o modifican su contenido. En el raro caso de necesitar detalles del esquema, es bastante fácil de encontrar. Para la consulta informal SELECT, es irrelevante. De hecho, considero que tratar las tablas y vistas es lo mismo que una gran ventaja.
A diferencia de las funciones y los 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.
Una función requiere que se llame al prefijo de 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 fuera así, se aplicaría lo mismo que 1.: si puedo tratar las funciones y los procedimientos almacenados de la misma manera, ¿por qué no debería hacerlo?

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

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

Si le da a su sproc este prefijo, SQL Server primero los busca en la base de datos maestra, luego en la base de datos de contexto, desperdiciando 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.

Here''s una buena explicación, que incluye una demostración del golpe de rendimiento.

Here''s otra fuente útil proporcionada por Ant en un comentario.

TableName_WhatItDoes

Comment_GetByID
Lista de clientes
UserPreference_DeleteByUserID

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

Una advertencia a lo anterior: personalmente siempre prefijo todo mi CRUD autogenerado con zCRUD_ para que ordene hasta el final de la lista donde no tengo que mirarlo.