¿Alguien puede recomendar estándares de codificación para TSQL?

9

Durante mucho tiempo hemos tenido estándares de codificación para nuestro código .Net, y parece haber varias fuentes acreditadas de ideas sobre cómo aplicarlas que evolucionan con el tiempo.

Me gustaría poder reunir algunos estándares para el SQL que está escrito para el uso de nuestros productos, pero no parece haber recursos disponibles sobre el consenso sobre lo que determina el SQL bien escrito.

Rowland Shaw
fuente
1
Pinal Dave tiene una lista de estándares de codificación en su sitio . Parecen una base justa para un conjunto de estándares.
Will A
1
Hay una pregunta relacionada sobre SO .
Scott Whitlock
1
@Scott que solo cubre la identificación; nada sobre nombres, uso de cursores / procedimientos almacenados / opciones de tipo de datos o cualquier cosa que realmente afecte la calidad del código ...
Rowland Shaw
1
exactamente, por eso dije que estaba "relacionado", no un "duplicado".
Scott Whitlock

Respuestas:

6

En mi experiencia, lo principal que buscaría sería:

  • Nombramiento de tablas y columnas: observe si usa ID, referencia o número para columnas de tipo ID, singular o plural para nombres (los plurales son comunes para nombres de tabla, por ejemplo, THINGS, singular para nombres de columna, por ejemplo, THING_ID). Para mí, lo más importante aquí es la coherencia que evita que las personas pierdan el tiempo (por ejemplo, no te encuentras con errores tipográficos en los que alguien ha puesto THING como nombre de tabla porque solo sabes intuitivamente que los nombres de tabla nunca son singulares).

  • Todas las creaciones deben incluir una caída (condicional al objeto existente) como parte de su archivo. Es posible que también desee incluir permisos de concesión, según usted.

  • Las selecciones, actualizaciones, inserciones y eliminaciones deben presentarse con un nombre de columna, un nombre de tabla y uno donde cláusula / orden por cláusula por línea para que puedan comentarse fácilmente uno a la vez durante la depuración.

  • Prefijo para tipos de objetos, particularmente donde pueden confundirse (por lo tanto, v para ver es lo más importante). No estoy seguro de si todavía se aplica, pero solía ser ineficiente para que los procedimientos almacenados que no sean los del sistema comiencen sp_. Probablemente la mejor práctica para diferenciarlos de todos modos usp_ fue lo que he usado más recientemente.

  • Un estándar que indica cómo el nombre de un activador debe incluir si es para actualizar / insertar / eliminar y la tabla a la que se aplica. No tengo un estándar preferido, pero esta es información crítica y debe ser fácil de encontrar.

  • Estándar para la propiedad de objetos en versiones anteriores de SQL Server o el esquema en el que debería existir para 2005 y posteriores. Es su decisión lo que es, pero nunca debe adivinar quién posee algo / dónde vive) y, cuando sea posible, el esquema / propietario debe incluirse en los scripts CREATE para minimizar la posibilidad de que se cree incorrectamente.

  • Un indicador de que cualquier persona que use SELECT * deberá tomar una pinta de su propia orina.

  • A menos que haya una muy, muy buena razón (que no incluye la pereza de su parte), tenga, haga cumplir y mantenga las relaciones de clave principal / clave externa desde el principio. Después de todo, esto es una base de datos relacional, no un archivo plano y los registros huérfanos harán que su vida de soporte sea un infierno en algún momento. También tenga en cuenta que si no lo hace ahora, puedo prometerle que nunca logrará implementarlo después del evento porque es 10 veces el trabajo una vez que tiene datos (lo cual será un poco complicado porque nunca hizo cumplir) las relaciones correctamente)

Estoy seguro de que me he perdido algo, pero para mí son los que realmente ofrecen un beneficio real en una cantidad decente de situaciones.

Pero como con todos los estándares, menos es más. Cuanto más largos sean sus estándares de codificación, es menos probable que las personas los lean y los usen. Una vez que pase un par de páginas bien espaciadas, comience a buscar dejar caer las cosas que realmente no están haciendo una diferencia práctica en el mundo real porque solo está reduciendo la posibilidad de que las personas hagan algo de eso.

EDITAR: dos correcciones, incluidos los esquemas en la sección de propiedad, eliminando una sugerencia errónea sobre el recuento (*) - vea los comentarios a continuación.

Jon Hopkins
fuente
1
Algunas elecciones extrañas ... "SELECCIONAR CONTEO (*)" es malo? ¿Has oído hablar de esquemas (que no es lo mismo que propietario)? Sin embargo
gbn
1
@ Jon Hopkins: sé por qué es malo usar SELECT *. Sería genial si pudieras decir por qué usar SELECT COUNT (*) es malo.
k25
1
@gbn @ k25 - Hace unos años (¿2002?) Tuve un DBA que era muy bueno en conteo (*) pero Google en respuesta a sus preguntas parece que ahora está desactualizado (si alguna vez fue cierto). sqlservercentral.com/articles/Performance+Tuning/adviceoncount/… (Se requiere registro). Ella era principalmente un DBA de Oracle, por lo que puede haber sido un problema genuino allí, que supuso que también era un problema para el optimizador de SQL.
Jon Hopkins
1
@gbn: Sí, aunque he estado relativamente alejado desde que se presentaron, por lo que mi reacción automática fueron los usuarios. Actualizaré la respuesta para cubrir los esquemas.
Jon Hopkins
1
@gbn, @ k25 - Más excavaciones en el recuento (*). Aparentemente, este era un problema en Oracle 7 y versiones anteriores, solucionado en 8i y más allá. No está claro si alguna vez fue un problema en SQL Server, pero ciertamente ya no lo es. Parece que mi DBA estaba desactualizado.
Jon Hopkins
3

no parece haber ningún recurso en el consenso sobre lo que determina SQL bien escrito

Eso es porque no hay consenso. Solo como ejemplo, tendría diferentes respuestas para al menos la mitad de los elementos en la lista de Jon Hopkins, y según la cantidad de detalles en su lista, es una suposición segura de que ambos trabajamos con bases de datos para vivir.

Dicho esto, un estándar de codificación sigue siendo algo bueno, y un estándar que todos en el equipo entiendan y estén de acuerdo es algo mejor, porque es más probable que se siga ese estándar.

Larry Coleman
fuente
1
+1. Creo que lo más importante es que tienes consistencia entre tu equipo.
Dean Harding
1
fuera de interés, ¿qué harías diferente? ¿Son en gran medida cuestiones de gusto (diseño, etc.) o hay algún error "difícil"?
Jon Hopkins
1
@ Jon: sin errores duros, solo cosas subjetivas como nombres de tablas singulares, odio a los desencadenantes, etc. Por cierto, "SELECT *" está bien dentro de un "EXISTS ()".
Larry Coleman
1
ejemplo justo (y lo uso con EXISTS y no me obligo a beber orina).
Jon Hopkins
1

Además de la respuesta de Jon Hopkins ...

  • Separar objetos internos vs externos

    • IX, UQ, TRG, CK, etc. para restricciones e índices, etc.
    • minúscula o CapsCase para el cliente, por ejemplo, uspThing_Add
  • Para objetos internos, explíquelos si son "no predeterminados"

    • UQ = restricción única
    • UQC = restricción agrupada única
    • PK = clave primaria
    • PKN = clave primaria no agrupada
    • IX = índice
    • IXU = índice único
    • IXC = índice agrupado
    • IXCU o IXUC = índice agrupado único
  • Use esquemas para simplificar los nombres + permisos. Ejemplos:

    • Helper.xxx para procesos internos
    • HelperFn.xxx para udfs
    • WebGUI.xxx para algunos códigos enfrentados
    • Datos y / o historial y / o estadificación para tablas
gbn
fuente