He trabajado con varias bases de datos grandes y los nombres de los procedimientos almacenados eran muy diferentes:¿Cuál es la mejor práctica de nombrar el procedimiento almacenado para t-sql?
SP_PrefixXXX
PrefixYyyXxx
Prefix: Rep, Act
Cuál es la mejor práctica de nombrar? ¿Cómo puedo organizarlos de manera adecuada?
La mejor convención de nombres es el que es constante a través de su base de datos :)
Realmente, le toca a usted y su equipo. Siempre y cuando sea claro y sensato, tienes un poco de margen de maniobra. Solo asegúrate de que sea lo que sea que decidas, todos se adhieren a él. Mucho más importante que la convención en sí es el hecho de que todos se apeguen a él.
Tiendo a evitar sp_, usp_ y similares, porque los encuentro redundantes. Por ejemplo, un sproc llamado InsertCustomer es claramente un sproc, y de ninguna manera podría confundirse con una tabla, vista o cualquier otro tipo de objeto. sp_ en particular debe evitarse.
Prefiero CamelCase, pero una vez más, esa es una cuestión de preferencia. Me gusta mi nombre proc para dar una buena indicación de lo que hace el proc - por ejemplo:
InsertSalesOrder PopulateItemStagingTables CalculateOrderSummary PrepareCustomerStatements
etc.
¡POR FAVOR, no use sp_! es como decir que tus puntos de vista necesitan un prefijo con view_ o tus tablas con table_ ... ¡en serio! metadata es ganar –
¿No es camelCase y PascalCase? –
Sí, o camelCase y UpperCase: 'camel' porque tiene una joroba en el medio. – ChrisW
Bueno, anteponiendo el nombre de "SP_" es bastante redundante: está dando nombre a la implementación (es un SP, a diferencia de una tabla o una vista). Hay muchas otras formas (systebales, information_schema, cómo lo usa) que le indicarán si está implementado.
En su lugar debe nombrarlo por su interfaz, por lo que hace por usted. Para mayor comodidad (como muchas cosas terminan ordenadas alfabéticamente), me gusta agrupar cosas similares bajo nombres similares, posiblemente usando el mismo prefijo.
Pero, de nuevo, el nombre de lo que hace, no cómo sucede a implementarse.
En general, creo que las convenciones de nomenclatura comunes para objetos de base de datos usan guiones bajos en lugar de CamelCase; esto es solo una cuestión de convención. Lo que no es mera convención es la convención también común de usar todas las letras minúsculas para los objetos de la base de datos; esto le permite ignorar la configuración del servidor que puede o no ser sensible a mayúsculas y minúsculas.
No "sp_", ni "usp_". Nosotros sabemos son procedimientos almacenados, el esquema de nombres no tiene que decirnos.
En general, solo les pongo un nombre por lo que hacen, posiblemente particionándolos en esquemas. Las excepciones son que usaré un prefijo "ssis_" para los procedimientos almacenados que no se usan directamente como parte de las operaciones de base de datos "normales", pero que son utilizados por un paquete SSIS para hacer referencia a la base de datos. Puedo usar "fn_" para indicar una función, para distinguirla de un procedimiento almacenado.
Tiendo a tratar de dar nombres que no solo den una idea para qué es la función, sino cuáles serán las variables de entrada.
Por ejemplo: ProcessMathEquationWithFieldIdPlantId
Esto ayudará a dar información de forma inmediata a cualquier otra persona a usarlo, creo.
También evito sp_ y usp_ para limitar cualquier posibilidad de colisión de nombres.
El prefijo sp_ significa Sistema de Procedimiento, y debe no se utiliza como prefijo para los procedimientos normales. Si lo hace, primero realizará un viaje adicional a la base de datos master cada vez que busque el procedimiento, y si tuviera el mismo nombre que uno de los procedimientos allí, ese procedimiento se ejecutará en lugar de su procedimiento.
Aparte de eso, puede crear cualquier convención de nomenclatura que desee. Uno utilizado por nuestra empresa es subsystem_object_action, p. main_Customer_Get. Eso pone los procedimientos que pertenecen juntos uno cerca del otro en la lista.
Usamos algo similar a eso donde estoy, excepto que un "Obtener" generalmente incluirá un poco más de descripción, como: main_Customer_Gy_By_ID –
@Tom: Getting by id puede ser visto como implícito en el "Obtener" si a uno le gusta, pero sí, por supuesto, hay otras acciones que necesitan una descripción más larga, como main_Customer_GetByRegion. Como ve, preferimos mantener los guiones bajos para separar los componentes del nombre y usar el caso Pascal para los nombres y acciones de la tabla. – Guffa
Probé su "primero hará un viaje extra al maestro" en SQL Server 2008R2: 1. Creé sp_Mine tanto en mi base de datos como en la maestra, la primera imprimiendo "mina n. ° 1" y la otra diciendo " maestro # 2 ". 2. Ejecute el proceso en mi db y ¡imprima la "mina n. ° 1"! Esperaría que si SQL Server va primero a master, hubiera encontrado el otro proc y hubiera impreso "master # 2" en su lugar ... 3. Pero luego creé "sp_autostats" en mi db (nombrado después de un sys proc en el maestro db) y en este caso llamó al maestro proc. ¿Tal vez su afirmación es correcta solo para [sys] procs en el maestro? – andreister
Me gusta prefijarlos para que los SP que tratan con objetos específicos se agrupen. Así que en lugar de algo así como:
InsertUser
UpdateUser
DeleteUser
GetUsers
lo hago de esta manera:
AppName_User_GetUser
AppName_User_InsertUser
AppName_User_UpdateUser
AppName_User_DeleteUser
Me parece que esto es más fácil para mí para gestionar en mi aplicación de administración de SQL y en mi código también.
Al igual que las otras personas Dicho esto, no uses el prefijo con sp_
Esta es una publicación anterior, pero me pareció útil confirmar que estaba nombrando sp's correctamente o utilizando las mejores prácticas. Comencé a usar el nombre (o iniciales) de la aplicación como un prefijo para procedimientos almacenados solo cuando el procedimiento solo se usa en esa aplicación Durante una modificación de una aplicación muy antigua, convertí todos los sql en línea a sp's. Después de crear muchas sp's, encontré que esta convención de nomenclatura les permitía agruparse y que era más fácil de encontrar cuando llegó el momento de recrearlas antes de moverlas a la base de datos de producción. – Doreen
_ ** AppName ** _ User_GetUser_ no es un buen nombre para un procedimiento almacenado IMO. Los procedimientos almacenados son objetos que deben ser genéricos reutilizables por cualquier aplicación que se conecte a la base de datos. ¿Qué sucede si tienes múltiples aplicaciones conectadas a la base de datos? ¿Qué pasa si el nombre de su aplicación cambia? He visto muchos procedimientos almacenados nombrados después de aplicaciones que se han ido hace mucho tiempo. Los objetos de la base de datos tienden a sobrevivir a la mayoría de las aplicaciones, así que nómbrelas sabiamente. – Yasir
No sé si realmente hay una específica 'mejores prácticas' en este caso. Con la compañía en la que me encuentro ahora, el estándar es usp [ProcedureName] (sin guiones bajos). Preferiría personalmente no tener ningún prefijo, pero si eres nuevo en una empresa o proyecto y tienen estándares preexistentes, a menos que estén usando sp_ cuando haya una razón técnica para no usar esto, probablemente no sea un tema que vale la pena debatir ya que ciertamente no creo que sea en este caso en absoluto un estándar atroz.
En general, volver a nombrar las convenciones, si tiene un debate y otros miembros del equipo no están de acuerdo con usted y el estándar de consenso es diferente, la mejor política es dejarlo ir rápidamente y aceptar el consenso; la coherencia es, por lo general, más importante que el estándar real en sí, ya que se lleva bien con otros miembros del equipo y no desarrolla una reputación de ser "difícil".
Estoy de acuerdo en que el consenso es lo principal para el equipo. – Galkin
No soy un profesional, pero me gusta esta manera
Prefijo de aplicación = XY; View = v; Procedimiento almacenado = p; Función = f
Table: XY_Name
View: vXY_Name
Procedure: sXY_Name
Function: fXY_Name
¿Qué opinas? Sé que algunas personas usan los dos caracteres para identificar el tipo de objeto, pero un personaje es suficiente para la mayoría de los casos, ¿no?
Mejor crear el esquema para el módulo separado.
A continuación, dar nombre significativo y simple.
Por ejemplo: si está trabajando en un proyecto escolar.
crear Estudiante esquema
nombre de procedimiento: AddStudent
Por lo tanto, se verá como Student.AddStudent en procedurelist
lo mismo para el Módulo Maestro
Entonces, ¿crea un esquema o base de datos para cada tabla? Esto es tan malo ... – leandronn
Esto puede ayuda. Como estoy delante/programador backend, utilizo el siguiente tanto para MySQL y SQL Server:
SPx_PAGE/MODULE_ACTION_OBJECT
x: R para leer I para insertar U para actualizar, W para la escritura (cosechadoras insertar si no existe índice o actualizar si existe) y D para eliminar.
página/módulo: el lugar que llama al procedimiento
Ejemplos:
SPR_DASHBOARD_GET_USERS //reads users data
SPW_COMPANIES_PUT_COMPANY //creates or modifies a company
Ver también: http://stackoverflow.com/questions/238267/what-is-your-naming-convention -for-stored-procedures? noredirect = 1 # comment22043254_238267 – DOK