sql3 novedades historia estandar caracteristicas sql coding-style

novedades - sql-86



¿Qué estándar de codificación SQL sigues? (14)

Desde un blog 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. Evite tipear inútilmente.

  2. Use alias para tablas / vistas. Siempre. Y hazlos alias sensibles.

  3. Sancionar el código de alguna manera.

  4. Evite las citas (sí, es por eso que odio a Django)

  5. Usar sintaxis de unión

Estoy de acuerdo con la capitalización de palabras reservadas y cualquier otro identificador, excepto el mío.

¿Existe algún estándar de codificación SQL ampliamente utilizado? SQL es un poco diferente del tipo de lenguaje de programación C / C ++. Realmente no sé cómo formatearlo mejor para la legibilidad.


Google para la impresora bonita sql o mira aquí . No lo he probado yo mismo, 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 gusta la coma que precede:

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

lo hace más fácil de leer y depurar en mi opinión.


No lo llamaría estándar de codificación, más como estilo de codificación

SELECT T1.col1, T1.col2, T2.col3 FROM table1 T1 INNER JOIN ON Table2 T2 ON T1.ID = T2.ID WHERE T1.col1 = ''xxx'' AND T2.Col3 = ''yyy''

  • capitalizar palabras reservadas
  • palabras clave principales en nueva línea
  • no se puede acostumbrar a las comas antes de las columnas
  • siempre use alias de tabla cortos y significativos
  • vistas de prefijo con v
  • prefijo procs almacenados con sp (sin embargo, no use "sp_" que está reservado para procs integrados)
  • no prefijo tablas
  • nombres de tabla singular

Personalmente, no me gusta prefijar un nombre de procedimiento almacenado con sp_ - es redundante, IMO. En cambio, me gusta agregarles un identificador de "unidad de funcionalidad". Por ejemplo, llamaré a los sprocs para tratar los pedidos order_Save, order_GetById, order_GetByCustomer, etc. Los mantiene lógicamente agrupados en el estudio de administración y hace que sea más difícil elegir el correcto. (GetOrderByProduct, GetCustomerById, etc.)

Por supuesto, es una preferencia personal, otras personas pueden preferir tener todos los sprocs juntos, todos los guardados, etc.

Solo mi 2c.


Por lo general, 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'' )


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

Y, antes de que alguien piense en anotar mi respuesta, consulte el siguiente artículo y los artículos relacionados sobre el bloqueo y vuelva a compilar; dos de los recursos más dañinos golpean 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 tipeo. Tanto que he creado mis propias aplicaciones SP para hacerlo por mí.

¡Los puntos que menciono son realmente importantes! Incluso podría decirse a sí mismo: "¿está bromeando? Eso no es un problema", bueno, entonces no leyó los artículos anteriores. Y , es totalmente estúpido que M $ ponga estos puntos como NOTES. Estos problemas para mí deberían ser NEGROS y GRITAR.

También hago una gran cantidad de codificación para construir mis scripts básicos usando aplicaciones C # para acelerar el desarrollo y estas prácticas son muy buenas (10 años) para hacer que los scripts SP sean más fáciles y especialmente más rápidos.

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

Mejores prácticas

  • Utilice los corchetes alrededor de los objetos, por lo que el motor de consulta conoce un campo de manera explícita cuando lo ve
  • Use EL MISMO CASO que los nombres de los objetos de tabla y los nombres de campo
  • Cuando llame a SP desde la aplicación, use el [dbo] totalmente calificado. [ProcName] con el propietario Y el caso correctos. ¡No bromeo! Lee los artículos de arriba!
  • Haga referencia al propietario del objeto para que la seguridad sea explícitamente conocida y no tenga que ser resuelta
  • NO nos "sp_" ya que esto se refiere a los procesos almacenados del sistema, y ​​a los gastos generales
  • Use SET NOCOUNT ON y SET NOCOUNT OFF para eliminar la sobrecarga adicional para realizar un seguimiento de cuántos registros se actualizan en el proceso almacenado a menos que los necesite. Normalmente, no lo haces y puedes obtener un gran aumento en el rendimiento.

Preferencias

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

Seleccionar

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

Actualizar

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

Insertar

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

Borrar

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



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 intenté construirla rápidamente como ejemplo ... pero ese no es el punto.

  • t_c significa sub-consulta de tabla de categorías o "categoría de temperatura".
  • _Indicador de cosas dentro de subconsultas.
  • alias nombres de columna para tener sentido en el contexto de la consulta. por ejemplo, "miembros activos"
  • poner comas al comienzo de las nuevas líneas facilita la creación de consultas dinámicas:

    $sql .= ", c.another_column"

  • todo lo demás es sencillo.


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


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 absolutamente legible, pero admito que es tedioso escribir. Si alinear correctamente 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


Tipos de datos que se utilizarán: deberíamos usar solo los siguientes tipos de datos:

  • EN T
  • BIGINT
  • SMALLINT
  • VARCHAR
  • POCO
  • FECHA Y HORA

Proporcione el valor predeterminado para el tipo de datos BIT. No debe ser anulable Los nombres de tabla y columna nunca deben estar en minúsculas. Debe describir su propósito. Evita usar formas cortas. Al crear una tabla FK y PK, debe pensarse y definirse bien. Los nombres de las variables deben comenzar con una o dos letras que indiquen su tipo de datos en minúsculas. Por ejemplo, la variable INT debe comenzar con i. El nombre debe ser descriptivo y las formas cortas deben evitarse. Cada palabra debe comenzar con la letra mayúscula seguida de todas las letras minúsculas.

P.ej

Forma correcta: - iTotalCount

Manera incorrecta: - xyz

Las columnas de tabla utilizadas con la cláusula "WHERE" dentro de los procedimientos almacenados deberían indexarse ​​/ modificarse. Esto aumentará la velocidad del procesamiento de datos. El orden de los parámetros en la cláusula WHERE debe hacerse correctamente. La clave / índice principal debe preceder a las variables de bit. Por ejemplo: - Se crea un índice en la combinación de columnas (REF_ID, T_TYPE_STR, CNUMBER, TLOG_ID)

- Forma correcta donde las claves indexadas se usan 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’

Mientras escribimos 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 cualquier sp, esta sección debe adjuntarse con

Modificado por:

Modificado en:

Descripción:

Las columnas ROW_INSERTION_DATE_TIME AND ROW_UPDATION_DATE_TIME deben tener valores predeterminados como GETDATE ().

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


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

Los nombres de tabla son singulares, como la tabla que sostiene que nuestros clientes serían la tabla de clientes

Las tablas de enlaces 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