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


122

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

¿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, ya que podría ser más importante que todos usen 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: creo que es una cuestión de legibilidad.
  • Se pueden segregar grandes colecciones de sprocs 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 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: tratar de usar Verbo + Sustantivo y luego no poder encontrar todas las aplicaciones que se aplican al Cliente.

Es muy importante poder localizar un sproc existente o determinar si incluso existe uno. Pueden surgir problemas graves si alguien crea inadvertidamente un sproc duplicado 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 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, 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.


1
¿Qué significa usp?
Midhat

2
Creo que usp es la abreviatura de "procedimiento de usuario". Eso lo distingue de los procedimientos del sistema con el prefijo "sp_". Esa es una distinción importante, como puedes leer en las respuestas.
DOK

gracias dok. Grazie Mille
Midhat


1
Estoy votando esto solo porque está cerrado, con suerte para mostrar los poderes de que preguntas como esta sean útiles para la comunidad.
tsilb

Respuestas:


66

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 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 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 de proceso, por ejemplo App_Product_AddAttribute.


3
¿Qué pasa si hay más de un objeto involucrado? Por ejemplo, ¿qué sucede si el sproc consulta información de la tabla Cliente y Pedidos?
DOK

2
Gracias Mitch, aclaremos. Ese prefijo "Aplicación" es un marcador de posición para otra abreviatura que indica el nombre (o acrónimo) real de la aplicación. Con 3 aplicaciones que comparten una base de datos, puede haber ICA_Product_Add, CRM_Product_Add y BPS_Product_Add.
DOK

2
¿Por qué duplicar cada procedimiento 3 veces para 3 aplicaciones? El objetivo de los procedimientos de la tienda es tener un solo lugar donde suceda una acción determinada. "ICA_Product_Add, CRM_Product_Add y BPS_Product_Add" destruye eso.
Jason Kester

3
Jason, esos sprocs pueden estar insertándose en diferentes tablas. Pueden tener diferentes parámetros de entrada o valores de retorno. O pueden tener un comportamiento diferente. Si los sprocs hacen lo mismo, estoy de acuerdo, solo debería haber una versión. Como alguien más sugirió, los sprocs compartidos podrían no tener prefijo.
DOK

1
Si tiene varias aplicaciones que llaman al mismo procedimiento, entonces debe tener mucho cuidado, cualquier modificación a ese proceso podría romper esas múltiples aplicaciones. Nombrando sabiamente, es un área gris, pero podría nombrarla común / global o cualquier cosa que considere conveniente. @localghosts: gracias por ser informativo.
dnolan

36

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 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 éxito en el rendimiento.

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


Hmm no entiendo. ¿Por qué sp da un golpe de rendimiento? ¿Usp o gsp están bien?
Erwin Rooijakkers

1
@ user2609980 DOK dice que SQL Server busca sp_primero el proceso prefijado en la base de datos maestra, luego en la base de datos actual si no se encuentra
GôTô

+1 por indicar claramente algo que tiene explicaciones más complicadas en otros lugares. No es una novedad para mí, pero creo que esta es una explicación simple y concisa para alguien que comienza.
Desanclar el

El enlace a la demostración del éxito de rendimiento es de un artículo escrito en 2001. Ha cambiado desde entonces, aquí hay un artículo más completo (de 2012) de Aaron Bertrand: sqlperformance.com/2012/10/t-sql-queries/sp_prefix
Michael J Swart

16

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

Compartimos muchos procedimientos almacenados en diferentes bases de datos de estructura similar, por lo que para los específicos de la base de datos, usamos un prefijo del nombre de la base de datos en sí; 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 "Agregar", "Establecer", "Generar", "Calcular", "Eliminar", etc., seguido de varios sustantivos más específicos como "Usuario" "," DailyRevenues ", y así sucesivamente.

En respuesta 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 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?

1
Entonces, ¿cómo sabes si estás interactuando con un procedimiento, una función, una vista, una tabla o cualquier otra cosa?
Ant

1
Me imagino que las funciones pueden comenzar con "Get" o ser un nombre que no comienza con un verbo. Todo lo demás sería un procedimiento porque, después de todo, se denominan procedimientos almacenados. Los procedimientos ocultan los detalles como vistas, tablas y cualquier otra cosa.
Mark Stock

3
Pero no es húngaro. La "usp" no es una declaración de variable húngara. La "u" no significa "actualización", significa "usuario", como en "procedimiento almacenado definido por el usuario", y simplemente protege de que SQL Server busque en la base de datos maestra cada vez que busca su procedimiento almacenado. Naturalmente, hay otras formas, pero la "usp" generalmente se considera un estándar en muchos cuerpos, y por lo que he visto funciona bien. También lo enseña Microsoft, y una convención de nomenclatura recomendada por Microsoft: msdn.microsoft.com/en-us/library/ms124456(v=SQL.100).aspx
asus3000

10

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 usa para elegir el especificador de acción. Por ejemplo, un INSERT del cliente puede requerir una gran cantidad de trabajo de preparación, pero el objetivo general es INSERT, por lo que se elige "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 "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

44
Ahora, hay una versión interesante del prefijo. Esa parece ser una buena manera de segregar sprocs por su uso.
DOK

10

TableName_WhatItDoes

  • Comment_GetByID

  • Lista de clientes

  • UserPreference_DeleteByUserID

Sin prefijos ni tonterías tontas húngaras. 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 se clasifique al final de la lista donde no tengo que mirarlo.


Separar los elementos "z" del resto parece una gran idea.
DOK

Me gusta este metodo Necesitan ser fáciles de encontrar. Cuando miro a través de una lista de los primeros sprocs verbales y veo 200 Gets, 200 Inserciones, 200 actualizaciones, es difícil encontrar todos los elementos para una tabla o agrupación específica. Primero utilicé el método del verbo, y se vuelve un desastre rápido. El nombre de la tabla primero resuelve este problema. Entonces, por ejemplo, en la respuesta anterior, todos sus Comentarios o Clientes se agruparían, es fácil de encontrar.
astrosteve

1
¿Y qué pasa si tiene una consulta que une varias tablas?
leandronn

10

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 tenues y de hecho 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. sp_hace que sea relativamente fácil identificar procedimientos almacenados que no son del sistema desde el diccionario de datos.


2
Nombrar sprocs "sp_" también es una muy mala idea para la velocidad, porque SQL Server intenta optimizar sus búsquedas para aquellos basados ​​en el supuesto de que son procedimientos del sistema. Eche un vistazo aquí, 5º punto abajo: rakph.wordpress.com/2008/04/19/tips-store-procedure
Ant

4

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

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.


Los paquetes son buenos. A partir de SQL Server 2005, Management Studio permite crear "soluciones" para almacenar sprocs relacionados y otras instrucciones SQL.
DOK

2
@DOK: tenga en cuenta que estos paquetes no tienen huella en la base de datos en sí. Son puramente artefactos de la herramienta front-end. No puede consultar por paquete en el diccionario de datos. Los paquetes de Oracle son objetos de primera clase en el diccionario de datos del sistema y tienen su propio alcance.
Preocupado por

4

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)

Intento 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)


Sí, gracias especialmente por abordar las abreviaturas.
DOK

@ [DOK]: de nada, ¿qué, sin voto? ;-)
Steven A. Lowe

Steve, tienes un voto a favor. Estaba demasiado ocupado leyendo la cantidad de respuestas y comentarios, y agonizando sobre qué respuesta es "mejor".
DOK

@ [DOK]: gracias; La "mejor" respuesta es probablemente la combinación que tenga sentido para su situación.
Steven A. Lowe

4

Actualmente uso un formato que es el siguiente

Notación:

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

Ejemplo:

P_CMS_USER_UserInfoGet

Me gusta esta notación por algunas 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.

2

Yo 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. El uso del prefijo "usp" me permite saber a qué estoy llamando si (por ejemplo) escribo 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.


2

aplicación prefijo_ operación prefijo_ 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 -

  • " Obtener ": devuelve un conjunto de registros
  • " Ins " - inserta datos
  • " Upd ": actualiza los datos
  • " Del ": elimina datos

p.ej

wmt_ ins _ detalles _ del cliente

"herramienta de gestión de la fuerza laboral, inserte detalles en la tabla del cliente"

ventajas

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

Este sistema funciona bien para nosotros, ya que tiene aprox. 1000 procedimientos almacenados en una base de datos fuera de mi cabeza.

No he encontrado ninguna desventaja en este enfoque hasta ahora.


Por lo general, aborrezco el uso de guiones bajos, pero la forma en que lo usa, no solo para segregar el prefijo, sino también para segregar la operación, facilitaría la búsqueda al escanear una lista de cientos de sprocs. Pretty_neat_idea.
DOK

2

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 según @ID


1

Creo que la convención de nombres usp_ no sirve de 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 ;-)


1
Prefijar cada sproc con _usp no ayuda a distinguir entre ellos. Creo que a algunos DBA les gusta ese prefijo porque indica el tipo de objeto de la base de datos. Tal vez tengamos noticias de uno de ellos a quien le guste.
DOK

1

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

Bueno, nunca se sabe, cuando está trabajando en una base de datos dedicada a una aplicación, si habrá otra aplicación más tarde usando la misma base de datos. En su situación, seguro que ayuda a segregar los sprocs.
DOK

1

No creo que realmente importe exactamente cuál es su prefijo siempre que sea lógico y consistente. 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. Mientras 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.


spu_, interesante. Esquiva el problema de SQL Server sp_.
DOK

1

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.

Para empezar, usamos un nombre común de Proc_. 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 en comparación con el 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 ayude.


1

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 <nombre de tabla> _G
Para eliminar datos: s <nombre de tabla> _D
Para insertar datos: s <nombre de tabla> _I
Para actualizar datos: s <nombre de tabla> _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 usamos las mismas convenciones de nomenclatura con poca diferencia:

Para obtener datos: sp_ <nombre de tabla> G
Para eliminar datos: sp_ <nombre de tabla> D
Para insertar datos: sp_ <nombre de tabla> I
Para actualizar datos: sp_ <nombre de tabla> U

Ejemplo:

exec sp_MedicationInfoG
exec sp_MedicationInfoD
exec sp_MedicationInfoI
exec sp_MedicationInfoU

Interesante. Nunca lo he visto así, pero es fácil recordar o adivinar los nombres correctos.
DOK

1
Gracias DOK, sí, es fácil de recordar y los desarrolladores nos sentimos libres de cualquier complejidad en los nombres
Gaurav Aroraa

9
¿Por qué no _C _R _U _D?
cuando el

@onedaywhen: es una buena idea, sugeriré a nuestro DBA para que podamos mantener las conversiones de nombres en consecuencia. Pero, el motivo principal de esta convención de nomenclatura es presentar todo el objeto correctamente, a menos que me haya perdido algo ...
Gaurav Aroraa

1
No se recomienda el prefijo "sp_".
Piyey
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.