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

StackOverflow https://stackoverflow.com/questions/238267

Pregunta

He visto varias reglas para nombrar procedimientos almacenados.

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

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

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

¿Utiliza una convención de nomenclatura? Descríbalo y explique por qué lo prefiere 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 nombres que la que se usa en particular.
  • Prefijos: aunque mucha gente usa usp_ o algo similar (pero raramente sp_), muchos otros usan la base de datos o el nombre de la aplicación. Un DBA inteligente utiliza gen, rpt y tsk para distinguir los procesadores CRUD generales de los que se utilizan para informes o tareas.
  • Verb + Noun 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 singulares y plurales para indicar si se están recuperando uno o varios registros.
  • Se sugiere una frase adicional al final, cuando corresponda. GetCustomerById, GetCustomerBySaleDate.
  • Algunas personas usan guiones bajos entre los segmentos de nombre y otros evitan los guiones bajos. app_ Get_Customer vs.appGetCustomer: supongo que es una cuestión de legibilidad.
  • Grandes colecciones de sprocs se pueden segregar en paquetes de Oracle o soluciones y proyectos de Management Studio (SQL Server), o esquemas de SQL Server.
  • Deben evitarse las abreviaturas inescrutables.

Por qué elijo la respuesta que hice: Hay TAN 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: tratar de usar Verbo + Sustantivo y luego no poder encontrar todas las aplicaciones que se aplican al Cliente.

Es muy importante poder localizar una sproc existente, o determinar si alguna existe. Pueden surgir problemas serios si alguien crea accidentalmente un duplicado sproc con otro nombre.

Como generalmente trabajo en aplicaciones muy grandes con cientos de sprocs, prefiero el método de denominación más fácil de encontrar. Para una aplicación más pequeña, podría recomendar Verbo + 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 del usp_ no muy útil. Como señalaron varias personas, a veces la base de datos contiene sprocs para múltiples aplicaciones. Por lo tanto, el prefijo con el nombre de la aplicación ayuda a segregar los sprocs Y ayuda a los DBA y otros a determinar para qué aplicación se usa el sproc.

¿Fue útil?

Solución

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

Debido a esto en mi nueva aplicación, estoy planeando agrupar nombres de procedimientos por objeto, también estoy descartando la usp porque siento que es algo redundante, aparte de decirme que es un procedimiento, algo que puedo deducir de el nombre del 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 las cosas para encontrarlas más tarde, especialmente si hay una gran cantidad de sprocs.

Con respecto 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 se hace referencia al secundario en la sección del proceso, por ejemplo App_Product_AddAttribute.

Otros consejos

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 de contexto, desperdiciando recursos innecesariamente. Y, si la sproc creada por el usuario tiene el mismo nombre que una sproc del sistema, la sproc creada por el usuario no se ejecutará.

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

Aquí hay una buena explicación, que incluye una demostración del rendimiento golpear.

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

Sistemas húngaros (como el " usp " anterior ; prefijo) me estremece.

Compartimos muchos procedimientos almacenados en diferentes bases de datos estructuradas de manera similar, por lo que para las específicas de la base de datos, 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 prefijos tan feos por completo.

El nombre real después del prefijo apenas difiere del nombre de la función: normalmente un verbo como " Add " ;, " Set " ;, " Generate " ;, " Calcular " ;, " Eliminar " ;, etc., seguido de varios sustantivos más específicos como " Usuario " ;, " DailyRevenues " ;, y así sucesivamente.

Respondiendo al comentario de Ant:

  1. 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 sus contenidos. En el raro caso de necesitar detalles específicos del esquema, es bastante fácil de encontrar. Para la consulta SELECT casual, es irrelevante. De hecho, considero que tratar las tablas y las vistas de la misma manera es 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 de esquema. De hecho, la sintaxis de la 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?

Iniciar un nombre de procedimiento almacenado con sp_ es incorrecto en SQL Server porque todos los sprocs del sistema comienzan 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. Por ejemplo, en un esquema en estrella, uno podría tener esquemas dim y fact y referirse a las tablas de esta convención.

Para los procedimientos almacenados, los prefijos son útiles para identificar las aplicaciones de las aplicaciones de las aplicaciones del sistema. up_ vs. <=> hace que sea relativamente fácil identificar procedimientos almacenados que no son del sistema del diccionario de datos.

TableName_WhatItDoes

  • Comment_GetByID

  • Lista de Clientes

  • UserPreference_DeleteByUserID

Sin prefijos o tonterías sin sentido húngaro. 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 todos mis CRUD autogenerados con zCRUD_ para que se clasifique al final de la lista donde no tengo que mirarlos.

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

Prefijo:

  • gen - General: CRUD, principalmente
  • rpt - Informe: autoexplicativo
  • tsk - Tarea: generalmente algo con lógica de procedimiento, ejecutado a través de 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 cliente INSERT puede requerir una gran cantidad de trabajo de preparación, pero el objetivo general es INSERTAR, así que & Se elige quot; Ins "

Objeto:

Para gen (CRUD), este es el nombre de la tabla o vista 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 & Quot; Por & Quot ;, & Quot; Para & Quot ;, 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). Eso reducirá la cantidad de objetos separados y reutilizará el código de ayuda.

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

para bases de datos pequeñas, uso uspTableNameOperationName, p. uspCustomerCreate, uspCustomerDelete, etc. Esto facilita la agrupación por entidad 'principal'.

para bases de datos más grandes, agregue un esquema o nombre de subsistema, p. Recibir, comprar, 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 personas nuevas en el proyecto no tienen que preguntarse qué significa 'UNAICFE' porque el sproc se llama uspUsingNoAbbreviationsIncreasesClarityForEveryone)

Actualmente utilizo un formato similar al siguiente

Notación:

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

Ejemplo:

P_CMS_USER_UserInfoGet

Me gusta esta notación por varias razones:

  • comenzar con un Prefijo muy simple permite escribir código para ejecutar solo objetos que comiencen 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 se ejecutan con 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 poder coincidir con Grupo / Aplicación, Módulo, Función desde la jerarquía.

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 qué puedo hacer con cualquier tabla. Usando el prefijo & Quot; usp & Quot; me permite saber a qué estoy llamando si (por ejemplo) estoy 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, mantendré los prefijos.

aplicación prefijo_ prefijo de operación_ descripción de los objetos de la base de datos involucrados (menos los espacios entre guiones bajos - tuvieron que poner espacios para que aparecieran) .

prefijos de operación que usamos -

  • & # 8220; obtener & # 8221; & # 8211; devuelve un conjunto de registros
  • & # 8220; ins & # 8221; & # 8211; inserta datos
  • & # 8220; upd & # 8221; & # 8211; actualiza los datos
  • & # 8220; del & # 8221; & # 8211; elimina datos

e.g

wmt_ins _ customer _details

" herramienta de administración de fuerza laboral, 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 ahora.

GetXXX - Obtiene XXX basado en @ID

GetAllXXX - Obtiene todos los XXX

PutXXX: inserta XXX si se pasa @ID es -1; más actualizaciones

DelXXX - Elimina XXX basado en @ID

Creo que la convención de nomenclatura usp_ no sirve para nada.

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

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 poder 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, generalmente 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 sea obvio lo que hace el procedimiento solo con el nombre.

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

shopGetCategories
shopUpdateItem

No creo que realmente importe exactamente cuál es su prefijo siempre que sea lógico y coherente. Personalmente uso

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 obtener, establecer, archivar, insertar, eliminar, etc. La descripción del proceso es algo breve pero descriptivo, por ejemplo 

spu_archiveCollectionData

o 

spu_setAwardStatus

Nombre mis funciones de manera similar, pero prefijo con udf_

He visto personas que intentan usar la 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í ese parece ser el punto óptimo entre el orden y el rigor innecesario

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

Entonces, si comienzas con algo diferente a sp_, las cosas se vuelven más fáciles.

Entonces usamos un nombre común de Proc_ para empezar. Eso facilita la identificación de 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 procesos almacenados que hacen el trabajo de POLL frente a los que hacen inventario, etc.

De todos modos, el sistema de prefijos depende del dominio del problema. Pero al dijo e hizo algo similar que debería estar presente, incluso si fuera solo para permitir que las personas ubiquen rápidamente el procedimiento almacenado en el menú desplegable de exploración para editarlo.

otros eg de la función. 

Proc_Order_Place
Proc_order_Delete
Proc_Order_Retrieve
Proc_Order_History

Seguimos la denominación basada en funciones porque los Procs son similares al código / función en lugar de objetos estáticos como tablas. No ayuda que los Procs puedan funcionar 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 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 usamos:

  

Para obtener datos: s < nombre de tabla > _G
  Para eliminar datos: s & Lt; tablename & Gt; _D
  Para insertar datos: s & Lt; tablename & Gt; _I
  Para actualizar datos: s & Lt; tablename & Gt; _U

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

Ejemplo : 

exec sMedicationInfo_G
exec sMedicationInfo_D
exec sMedicationInfo_I
exec sMedicationInfo_U

Con la ayuda de las convenciones de nomenclatura anteriores en nuestra aplicación, tenemos nombres buenos y fáciles de recordar.

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

  

Para obtener datos: sp _ < nombre de tabla > G
  Para eliminar datos: sp _ & Lt; nombre de tabla & Gt; D
  Para insertar datos: sp _ & Lt; tablename & Gt; I
  Para actualizar datos: sp _ & Lt; nombre de tabla & Gt; U

Ejemplo : 

exec sp_MedicationInfoG
exec sp_MedicationInfoD
exec sp_MedicationInfoI
exec sp_MedicationInfoU
Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top