novedades - sql-86

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

Question

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

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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

Answer 5

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.

Answer 6

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

Answer 7

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

Answer 8

Si buscas en Google, existen muchos estándares de codificación. Por ejemplo,

Estándar de Codificación de Bases de Datos y Directriz

y

SQL SERVER Database Coding Standards and Guidelines Lista completa

Answer 9

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.

Answer 10

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

Answer 11

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

Answer 12

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/

Answer 13

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

Answer 14

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