¿Qué estándar de codificación SQL sigue? [cerrado]

Me gusta la coma que precede:

SELECT
      column1
    , column2
    , column3
    , COALESCE(column4,'foo') column4
FROM
    tablename
WHERE
    column1 = 'bar'
ORDER BY 
      column1
    , column2

Hace que sea más fácil de leer y depurar en mi opinión.

Sé que esto es largo, pero ten paciencia conmigo, es importante. Esta pregunta abrió una lata de gusanos. Y si no te gustan los bloques de base de datos, sigue leyendo.

Y, antes de que alguien piense en derribar mi respuesta, por favor vea el siguiente artículo y los artículos conectados a él sobre el bloqueo y recompila; dos de los recursos más dañinos en una base de datos SQL.

Http://support.microsoft.com/kb/263889

Puedo escribir bastante rápido, y no me gusta escribir más que la siguiente persona. Pero los puntos a continuación sigo muy de cerca, incluso si es más escribiendo. Tanto que he construido mis propias aplicaciones SP para hacerlo por mí.

Los puntos que menciono son realmente importantes! Incluso podrías decirte a ti mismo, "estás bromeando, eso no es un problema", bueno, entonces no has leído los artículos anteriores. Y, es totalmente estúpido que M put pusiera estos puntos como notas. Estas cuestiones para mí deben ser AUDACES y GRITAR.

También hago mucho código para construir mis scripts básicos usando aplicaciones C# para acelerar el desarrollo y estas prácticas son muy sólidas (vale la pena 10 años) para hacer que el SPS de scripting sea más fácil y especialmente más rápido.

Hay más que esto, pero esto es lo que hago para el primer 60% de todo.

Mejores prácticas

• Use los corchetes alrededor de los objetos, de modo que el motor de consultas sepa excplícitamente un campo cuando lo vea
• Utilice EL EL MISMO CASO que los nombres de objetos de tabla y nombres de campos
• Cuando llame a SPs desde la aplicación, utilice el [dbo] completamente calificado.[procName] con el propietario Y el caso correctos. ¡No Bromees! Leer los artículos de arriba!
• Haga referencia al propietario del objeto para que la seguridad se conozca explícitamente y no tenga que averiguarse
• NO nos "sp_" ya que esto se refiere a procs almacenados en el sistema, y sobrecarga
• Use SET NOCOUNT ON y SET NOCOUNT OFF para eliminar la sobrecarga adicional para realizar un seguimiento de cómo muchos registros se actualizan en el proc almacenado a menos que los necesite. Normalmente, no lo hace y puede obtener un gran aumento en el rendimiento.

Preferencias

• Prefijo almacenado procs con proc
• Sufijo cada proc almacenado con SEL, UPD, DEL, INS (o SELECT, UPDATE, DELETE, INSERT)
• Mayúscula las palabras reservadas
• Palabras clave principales en la nueva línea (scripting)
• Usar comas antes de columnas (scripting)
• Vistas de prefijo con vw
• No ponga prefijos a las tablas
• Nombres de tabla singular
• Agregue un sufijo a los nombres estándar como "_ByPK", "_OrderByLastName", o "_Top15Orders" para variaciones en el stock SP

Seleccione

CREATE PROC [dbo].[procTable_SEL]
AS
SET NOCOUNT ON
SELECT
    [Column1] = T1.[col1]
  , [Column2] = T1.[col2]
  , [Column3] = T2.[col3]
FROM [dbo].[Table] T1    
INNER JOIN ON [dbo].[Table2] T2 ON T1.ID = T2.ID
WHERE
      T1.[col1] = 'xxx'
  AND T2.[Col3] = 'yyy'
SET NOCOUNT OFF
GO

Actualización

CREATE PROC [dbo].[procTable_UPD]
AS
SET NOCOUNT ON
UPDATE t1 SET
    [Column1] = @Value1
  , [Column2] = @Value2
  , [Column3] = @Value3
FROM [dbo].[Table1] T1
INNER JOIN ON [dbo].[Table2] T2 ON T1.[ID] = T2.[ID]
WHERE
      T1.[col1] = 'xxx'
  AND T2.[Col3] = 'yyy'
SET NOCOUNT OFF
GO

Insértese

CREATE PROC [dbo].[procTable_INS]
AS
SET NOCOUNT ON
INSERT INTO [Table1] (
[Column1]
  , [Column2]
  , [Column3]
)
VALUES (
    @Value1
  , @Value2
  , @Value3
)
SET NOCOUNT OFF
GO

O

CREATE PROC dbo.procTable_INS
AS
SET NOCOUNT ON
INSERT INTO [table1] (
    [Column1]
  , [Column2]
  , [Column3]
)
SELECT
    [Column1] = T1.col1
  , [Column2] = T1.col2
  , [Column3] = T2.col3
FROM dbo.Table1 T1    
INNER JOIN ON Table2 T2 ON T1.ID = T2.ID
WHERE
      T1.[col1] = 'xxx'
  AND T2.[Col3] = 'yyy'
SET NOCOUNT OFF
GO

Suprímase

CREATE PROC dbo.procTable_DEL
AS
SET NOCOUNT ON
DELETE
FROM [dbo].[Table1] T1
INNER JOIN ON [dbo].[Table2] T2 ON T1.[ID] = T2.[ID]
WHERE
      T1.[col1] = 'xxx'
  AND T2.[Col3] = 'yyy'
SET NOCOUNT OFF
GO

Si Google, hay un montón de estándares de codificación por ahí. Por ejemplo,

Norma y Guía de Codificación de Bases de datos

Y

Normas y Directrices de Codificación de Bases de datos de SQL SERVER Lista Completa

De un blog realmente muy bueno en PostgreSQL, pero este tema es aplicable en general:

Consultas mantenibles-mi punto de vista (depesz.com)

...Decidí que mis prioridades para escribir consultas mantenibles:

1. Evita escribir de forma inútil.

2. Utilice alias para tablas/vistas. Siempre. Y que sean sensatos apodo.

3. Código de sangría de alguna manera.

4. Evitar citas (sí, esto es por eso que hate Django)

5. Usar sintaxis de unión

Estoy de acuerdo con la mayúscula de las palabras reservadas y cualquier otro identificador, excepto el mío.

Personalmente no me gusta anteponer un nombre de procedimiento almacenado con sp_ - es redundante, IMO. En su lugar, me gusta prefijarlos con un identificador de "unidad de funcionalidad". por ejemplo, voy a llamar a los sprocs para tratar con orders order_Save, order_GetById, order_GetByCustomer, etc. Los mantiene todos agrupados lógicamente en management studio y hace que sea más difícil elegir el equivocado. (GetOrderByProduct, GetCustomerById, etc...)

Por supuesto, es una preferencia personal, otras personas pueden preferir ten todos los Get sprocs juntos, todos los Save ones, etc.

Solo mi 2c.

Generalmente mantengo muy poco por línea, es decir:

select
    col1,
    col2,
    col3
from
    some_table tabl1
where
    col1 = 'some'
and 
(
    col2 = 'condition'
or  col2 = 'other'
)

Google para sql pretty printer o mira aquí . Yo no lo he probado, pero te da un buen comienzo. La mayoría de las herramientas comerciales como Toad tienen una opción de "formateo" que también ayuda.

Me sorprende que el estilo de codificación que he usado durante casi 20 años no esté en esta lista:

  SELECT column1,
         column2,
         column3,
         COALESCE(column4, 'foo') AS column4
    FROM tablename
   WHERE column1 = 'bar'
ORDER BY column1,
         column2

Encuentro esto el absolutamente más legible, pero admito que es tedioso escribir. Si alinear a la derecha las palabras clave es demasiado, optaría por alinearlas a la izquierda:

SELECT   column1,
         column2,
         column3,
         COALESCE(column4, 'foo') AS column4
FROM     tablename
WHERE    column1 = 'bar'
ORDER BY column1,
         column2

Juega con www.sqlinform.com - Recomiendo usar el estándar ANSI-92, y luego arreglarlo con ese sitio.

SELECT c.id
     , c.name
     , c.folder
     , cs.num_users active_members
     , cs.num_videos

  FROM campaign c
  JOIN campaign_stats cs
    ON cs.campaign_id = c.id
  JOIN (SELECT _c.id
             , _c.name

          FROM campaign _c
         WHERE _c.type = 9) t_c 
    ON t_c.id = c.id

 WHERE c.id IN (1,2,3)
   AND cs.num_videos > 10

Esto funciona bastante bien para nosotros.

Esta consulta real no tiene mucho sentido ya que traté de construirla rápidamente como un ejemplo... pero ese no es el punto.

• t_c significa sub-consulta de tabla de categorías o "categoría temporal".
• _ubscripción de cosas dentro de sub-consultas.
• nombres de columna de alias para tener sentido en el contexto de la consulta. por ejemplo," active_members "

• Poner comas al principio de las nuevas líneas facilita la construcción dinámica consultas:

  $sql .= ", c.another_column"
  

• Todo lo demás es sencillo.

Cualquier cosa en azul es mayúscula SELECT, DELETE, GO, etc

Los nombres de las tablas son singulares como la tabla que contiene a nuestros clientes sería la tabla de clientes

Las tablas de enlace son tablename_to_tablename

Use _ entre trabajos en nombres de tablas y parámetros

Ejemplo

BEGIN
    SELECT
        Company.ID AS Company_ID,
        Company.Client_Name,
        Company.Website,
        Office.Office_Name
    FROM
        Company_Office WITH(NOLOCK)
        INNER JOIN Company WITH(NOLOCK) ON Company_Office.Company_ID = Company.ID
    WHERE
END

Tipos de datos a utilizar: Debemos usar solo los siguientes tipos de datos:

• INT
• BIGINT
• SMALLINT
• VARCHAR
• BIT
• DATETIME

Proporcione el valor predeterminado para el tipo de datos de BITS. No debe ser anulable Los nombres de las tablas y columnas nunca deben estar en minúsculas. Debe describir su propósito. Evite usar formularios cortos. Al crear una tabla FK y PK para ser bien pensado y definido. Los nombres de las variables deben comenzar con una / dos letras indicando su tipo de datos en minúsculas. Por ejemplo, la variable INT debe comenzar con i. El nombre debe ser descriptivo y se deben evitar las formas cortas. Ella cada palabra debe comenzar con la letra mayúscula seguida de todas las letras pequeñas.

Por ejemplo

Manera correcta: - iTotalCount

Forma incorrecta: - xyz

Las columnas de tabla utilizadas con la cláusula "WHERE" dentro de los procedimientos almacenados deben ser indexadas/tecleadas. Esto aumentará la velocidad del procesamiento de datos. Orden de los parámetros en la cláusula WHERE debe ser hecho correctamente. La clave/índice primario debe preceder a las variables de bits. Por ejemplo: - Se crea un índice en combinación de columnas (REF_ID, T_TYPE_STR, CNUMBER, TLOG_ID)

- Forma correcta en la que las claves indexadas se utilizan en secuencia en la cláusula 'WHERE'

SELECT REF_ID,T_TYPE_STR,C_NUMBER,TLOG_ID

FROM T_T_DATA_tbl

WHERE REF_ID = 1

AND LOG_ID = ‘4042654’

AND T_TYPE_STR = ‘SA’

AND CNUMBER = ‘10702’

–Incorrect way

SELECT REF_ID, T_TYPE_STR, CNUMBER, LOG_ID

FROM T_T_DATA_tbl

WHERE LOG_ID = ‘4042654’

AND T_TYPE_STR = ‘SA’

Al escribir un procedimiento almacenado debemos tener una sección de descripción al principio que contendrá Autor:

Fecha de creación:

Descripción:

Si se modifica alguna pe, esta sección debe adjuntarse con

Modificado por:

Modificado el:

Descripción:

LAS columnas ROW_INSERTION_DATE_TIME Y ROW_UPDATION_DATE_TIME deben tener valores predeterminados como GETDATE().

Más en : http://www.writeulearn.com/sql-database-coding-standards /

create table
    #tempTable (
        col1 int,
        col2 int,
        col3 int
    )

insert into
    #tempTable (
        col1,
        col2,
        col3
    )
    select
        col1,
        col2,
        col3
    from
        Table3
        inner join Table2
            on Table1.col1 = Table2.col2
    where col1 = 5

select
    col2,
    case when col1 = 3
        then 'something'
        else 'somethingelse'
    end
from #tempTable
where
    col1 = 5
    and (
        col2 = 5
        or col3 in (
            select field
            from Table2
            where
                somecol = 2
                and othercol = 5
        )
    )