query - separador de miles sql

Estándares de formato SQL

Question

En mi último trabajo trabajamos en una gran aplicación de base de datos y desarrollé algunos estándares de formato para que todos escribiéramos SQL con un diseño común. También desarrollamos estándares de codificación, pero estos son más específicos de la plataforma, así que no entraré en ellos aquí.

Me interesa saber qué usan otras personas para los estándares de formato SQL. A diferencia de la mayoría de los entornos de codificación, ya que no he encontrado mucho consenso en línea para ellos.

Para cubrir los principales tipos de consulta:

select
    ST.ColumnName1,
    JT.ColumnName2,
    SJT.ColumnName3
from 
    SourceTable ST
inner join JoinTable JT
    on JT.SourceTableID = ST.SourceTableID
inner join SecondJoinTable SJT
    on ST.SourceTableID = SJT.SourceTableID
    and JT.Column3 = SJT.Column4
where
    ST.SourceTableID = X
    and JT.ColumnName3 = Y

Hubo algún desacuerdo sobre las alimentaciones de línea después de "seleccionar", "de" y "dónde". La intención en la línea de selección es permitir que otros operadores como "X superior" sin alterar el diseño. Después de eso, simplemente mantener un flujo de línea consistente después de los elementos de consulta clave, pareció dar como resultado un buen nivel de legibilidad.

Dejar caer el salto de línea después de "desde" y "dónde" sería una revisión comprensible. Sin embargo, en consultas como la "actualización" a continuación, vemos que el avance de línea después del "dónde" nos da una buena alineación de columnas. Del mismo modo, un salto de línea después de "agrupar por" o "ordenar por" mantiene nuestros diseños de columna claros y fáciles de leer.

update
    TargetTable
set
    ColumnName1 = @value,
    ColumnName2 = @value2
where
    Condition1 = @test

Finalmente un inserto:

insert into TargetTable (
    ColumnName1,
    ColumnName2,
    ColumnName3
) values (
    @value1,
    @value2,
    @value3
)

En su mayor parte, estos no se desvían tanto de la forma en que MS SQL Server Management Studio / query analyzer escribe SQL, sin embargo , difieren.

Estoy ansioso por ver si hay algún consenso en la comunidad de Stack Overflow sobre este tema. Estoy constantemente sorprendido de cuántos desarrolladores pueden seguir el formato estándar para otros idiomas y de repente van tan al azar cuando tocan SQL.

Answer 1

Bonito. Como programador de Python, estas son mis preferencias:

Líneas nuevas después de "seleccionar", "de" y "dónde" solo cuando es necesario para la legibilidad.

Cuando el código de código puede ser más compacto e igualmente legible, generalmente prefiero la forma más compacta. Ser capaz de incluir más código en una pantalla mejora la productividad.

select ST.ColumnName1, JT.ColumnName2, SJT.ColumnName3
from SourceTable ST
inner join JoinTable JT
    on JT.SourceTableID = ST.SourceTableID
inner join SecondJoinTable SJT
    on ST.SourceTableID = SJT.SourceTableID
    and JT.Column3 = SJT.Column4
where ST.SourceTableID = X and JT.ColumnName3 = Y

En última instancia, esta será una llamada de juicio que se realizará durante la revisión del código.

Para insert , colocaría los parens de manera diferente:

insert into TargetTable (
    ColumnName1,
    ColumnName2,
    ColumnName3)
values (
    @value1,
    @value2,
    @value3)

El razonamiento para este formato es que si SQL usó idendation para estructura de bloque (como Python), entonces el paréntesis no sería necesario. Entonces, si la sangría se usa de todos modos, los paréntesis deberían tener el efecto mínimo en el diseño. Esto se logra colocándolos al final de las líneas.

Answer 2

Creo que tener unas buenas reglas de formato es realmente importante porque puedes detectar y corregir errores fácilmente. Como se dice: "Está escribiendo código una vez, este código se lee y luego 10000000 de veces", por lo que siempre es bueno dedicar algo de tiempo al formateo. Los objetivos principales son:

• Haga que su código sea más fácil de leer y entender
• Minimice el esfuerzo requerido para mantener o extender su código
• Reduzca la necesidad de que los usuarios y desarrolladores de un sistema consulten fuentes secundarias de documentación, como comentarios de códigos o manuales de software

Algunas reglas que siempre uso:

• Siempre usa . notación
• Siempre use alias antes de la columna, entonces. notación
• Pongo yo and hasta el final de la línea
• No use soportes de unnishccary
• No use MAYÚSCULAS
• Por lo general, prefiere cte a subconsultas anidadas

Como ejemplo, aquí cómo formatearía la consulta utilizada como ejemplo en esta pregunta:

select
    ST.ColumnName1,
    JT.ColumnName2,
    SJT.ColumnName3
from <schema>.SourceTable as ST
    inner join <schema>.JoinTable as JT on
        ST.SourceTableID = JT.SourceTableID
    inner join <schema>.SecondJoinTable as SJT on
        SJT.SourceTableID = ST.SourceTableID and
        SJT.Column4 = JT.Column3
where
    ST.SourceTableID = X and
    JT.ColumnName3 = Y

Y consulta de "estudiantes":

select
    term,
    student_id,
    case
        when (ft_credits > 0 and credits >= ft_credits) or (ft_hours_per_week > 3 and hours_per_week >= ft_hours_per_week) then ''F''
        else ''P''
    end as [status]
from (
    select
        a.term,
        a.student_id,
        pm.credits as ft_credits,
        pm.[hours] as ft_hours_per_week,
        sum(a.credits) as credits,
        sum(a.hours_per_week) as hours_per_week
    from (
        select
            e.term, e.student_id, NVL(o.credits, 0) credits,
            case
                when NVL(o.weeks, 0) > 5 then
                    (NVL(o.lect_hours, 0) + NVL(o.lab_hours, 0) + NVL(o.ext_hours, 0)) / NVL(o.weeks, 0)
                else
                    0
            end as hours_per_week
        from enrollment as e
            inner join offering as o using (term, offering_id)
            inner join program_enrollment as pe on pe.student_id = e.student_id and pe.term = e.term and pe.offering_id = e.offering_id
        where
            e.registration_code Not in (''A7'', ''D0'', ''WL'')
    ) as a
        inner join student_history as sh using (student_id)
        inner join program_major as pm on pm._major_code = sh.major_code_1 and pm.division_code = sh.division_code_1
    where
        sh.eff_term = 
            (
                select max(eff_term)
                from student_history as shi
                where
                    shi.student_id = sh.student_id and
                    shi.eff_term <= term
             )
    group by
        a.term,
        a.student_id,
        pm.credits,
        pm.[hours]
) as a
order by
    term,
    student_id

Answer 3

El número de opiniones diferentes es aterrador. Esto es lo que mi organización usa:

 SELECT ST.ColumnName1,
        JT.ColumnName2,
        SJT.ColumnName3
   FROM SourceTable ST
  INNER JOIN JoinTable JT ON JT.SourceTableID = ST.SourceTableID
  INNER JOIN SecondJoinTable SJT ON ST.SourceTableID = SJT.SourceTableID 
        AND JT.Column3 = SJT.Column4
  WHERE ST.SourceTableID = X
    AND JT.ColumnName3 = Y

Mantener la sangría de 8 caracteres es clave para la legibilidad en mi humilde opinión.

Answer 4

Estoy totalmente de acuerdo con su esfuerzo por estandarizar el formato SQL dentro de su proyecto y en general.

También estoy muy de acuerdo con sus opciones de formato. He encontrado casi el mismo, salvo que también sangré las declaraciones ''join'', y con ellas las declaraciones ''on'' una sangría más.

Muy parecido al hecho de que vayas en minúsculas en las palabras clave. ¿Quién quiere recibir esas GRACIAS? También prefiero reducir los alias de la tabla de casos, lo que permite una mejor legibilidad

Muy parecido al hecho de que usas una pequeña sangría (4). Voy con (3).

Considero que los términos "interno" y "externo" no son necesarios.

Aquí es cómo habría formateado su declaración seleccionada:

select
   st.ColumnName1,
   jt.ColumnName2,
   sjt.ColumnName3
from 
   SourceTable st
   join JoinTable jt on jt.SourceTableID = st.SourceTableID
   join SecondJoinTable sjt on
      st.SourceTableID = sjt.SourceTableID and
      jt.Column3 = sjt.Column4
where
   st.SourceTableID = X
   and jt.ColumnName3 = Y
;

Gracias por discutir esto.

Answer 5

Estoy trabajando en la escritura de un formateador de SQL de fuente abierta (SQL Server solo en esta etapa) en C #, así que puse las consultas anteriores a través de él.

Emplea una estrategia similar al OP, es decir, que cada ''sección'' tiene elementos secundarios sangrados debajo. Cuando sea necesario, agrego un espacio en blanco entre las secciones para ayudar a la claridad; estas no se agregarán cuando no haya uniones o un mínimo donde las condiciones

Resultado:

SELECT
    ST.ColumnName1,
    JT.ColumnName2,
    SJT.ColumnName3

FROM SourceTable ST

INNER JOIN JoinTable JT
        ON JT.SourceTableID = ST.SourceTableID

INNER JOIN SecondJoinTable SJT
        ON ST.SourceTableID = SJT.SourceTableID
       AND ST.SourceTable2ID = SJT.SourceTable2ID

WHERE ST.SourceTableID = X
  AND JT.ColumnName3 = Y
  AND JT.Column3 = SJT.Column4

ORDER BY
    ST.ColumnName1

Answer 6

Hay muchos puntos buenos en este hilo. El único estándar que he intentado convencer a las personas para que utilicen es colocar la coma en la misma línea antes de cada columna. Al igual que:

Select column1
   ,column2
   ,column3
   ,column4
   ,Column5 ...ect

Oposición a:

Select column1,
   column2,
   column3, ect...

La razón por la que prefiero esta práctica es porque, si es necesario, puedes comentar una línea y no habrá un problema de coma cuando lo ejecutes debido a que la coma correspondiente está siendo comentada también. Sé que vi a otro usuario en el hilo que también lo había hecho pero que en realidad no lo señaló. No es una gran revelación para llevar a la conversación, pero mis dos centavos. Gracias

Answer 7

Llego tarde a la fiesta, pero solo agregaré mi estilo de formato preferido, que debo haber aprendido de libros y manuales: es compacto. Aquí está la declaración SELECT muestra:

SELECT  st.column_name_1, jt.column_name_2,
        sjt.column_name_3
FROM    source_table AS st
        INNER JOIN join_table AS jt USING (source_table_id)
        INNER JOIN second_join_table AS sjt ON st.source_table_id = sjt.source_table_id
                AND jt.column_3 = sjt.column_4
WHERE   st.source_table_id = X
AND     jt.column_name_3 = Y

En resumen: sangría de 8 espacios, palabras clave en mayúsculas (aunque SO los colorea mejor cuando está en minúsculas), sin camelcase (sin sentido en Oracle) y envolturas de línea cuando sea necesario.

La UPDATE :

UPDATE  target_table
SET     column_name_1 = @value,
        column_name_2 = @value2
WHERE   condition_1 = @test

Y el INSERT :

INSERT  INTO target_table (column_name_1, column_name_2,
                column_name_3)
VALUES  (@value1, @value2, @value3)

Ahora, déjame ser el primero en admitir que este estilo tiene sus problemas. La sangría de 8 espacios significa que ORDER BY y GROUP BY desalinean la sangría o dividen la palabra BY off por sí misma. También sería más natural aplicar sangría al predicado completo de la cláusula WHERE , pero generalmente alineo los siguientes operadores AND y OR en el margen izquierdo. La sangría después de las líneas envueltas INNER JOIN también es algo arbitraria.

Pero por alguna razón, todavía me resulta más fácil de leer que las alternativas.

Terminaré con una de mis creaciones más complejas últimamente usando este estilo de formateo. Casi todo lo que encontrarías en una declaración SELECT aparece en este. (También se ha alterado para ocultar sus orígenes, y es posible que haya introducido errores al hacerlo).

SELECT  term, student_id,
        CASE
            WHEN ((ft_credits > 0 AND credits >= ft_credits) OR (ft_hours_per_week > 3 AND hours_per_week >= ft_hours_per_week)) THEN ''F''
            ELSE ''P''
        END AS status
FROM    (
        SELECT  term, student_id,
                pm.credits AS ft_credits, pm.hours AS ft_hours_per_week,
                SUM(credits) AS credits, SUM(hours_per_week) AS hours_per_week
        FROM    (
                SELECT  e.term, e.student_id, NVL(o.credits, 0) credits,
                        CASE
                            WHEN NVL(o.weeks, 0) > 5 THEN (NVL(o.lect_hours, 0) + NVL(o.lab_hours, 0) + NVL(o.ext_hours, 0)) / NVL(o.weeks, 0)
                            ELSE 0
                        END AS hours_per_week
                FROM    enrollment AS e
                        INNER JOIN offering AS o USING (term, offering_id)
                        INNER JOIN program_enrollment AS pe ON e.student_id = pe.student_id AND e.term = pe.term AND e.offering_id = pe.offering_id
                WHERE   e.registration_code NOT IN (''A7'', ''D0'', ''WL'')
                )
                INNER JOIN student_history AS sh USING (student_id)
                INNER JOIN program_major AS pm ON sh.major_code_1 = pm._major_code AND sh.division_code_1 = pm.division_code
        WHERE   sh.eff_term = (
                        SELECT  MAX(eff_term)
                        FROM    student_history AS shi
                        WHERE   sh.student_id = shi.student_id
                        AND     shi.eff_term <= term)
        GROUP   BY term, student_id, pm.credits, pm.hours
        )
ORDER   BY term, student_id

Esta abominación calcula si un estudiante es a tiempo completo o a tiempo parcial en un término determinado. Independientemente del estilo, este es difícil de leer.

Answer 8

Me doy cuenta de que llegué muy tarde a este debate, pero me gustaría dar mi opinión. Definitivamente estoy a favor de las comas al inicio de la línea. Como dices AdamRalph es más fácil comentar un campo y también me resulta más difícil perder una coma accidentalmente cuando están al principio, aunque esto no suena como un problema importante. He pasado horas tratando de hacerlo en el pasado. para rastrear errores de sintaxis accidentales en largos procedimientos de T-SQL donde accidentalmente he perdido una coma al final de la línea (estoy seguro de que algunos de ustedes probablemente lo hayan hecho también). También estoy a favor de aliasing tanto como sea posible.

En general, me doy cuenta de que todo se reduce a las preferencias personales, lo que funciona para algunos no lo es para los demás. Siempre que pueda leer el código fácilmente y cada desarrollador muestre cierta consistencia en su estilo, creo que eso es lo más importante.

Answer 9

Me gusta que mi SQL esté formateado de esa manera, aunque mientras la intención sea fácil de leer, la mayoría de los formatos funcionarán. Realmente odio ver las declaraciones creadas en el diseñador de consultas y luego me fui de esa manera. Si estoy editando el procedimiento / vista / función / disparador de otra persona, etc., intentaré mantener el formato ya utilizado (a menos que sea realmente malo, lo reformatearé todo).

Seleccionar declaración

SELECT ST.ColumnName1, JT.ColumnName2, SJT.ColumnName3
  FROM SourceTable ST INNER JOIN
       JoinTable JT ON JT.SourceTableID = ST.SourceTableID 
       INNER JOIN
       SecondJoinTable SJT ON ST.SourceTableID = SJT.SourceTableID
                          AND JT.Column3 = SJT.Column4
WHERE (ST.SourceTableID = X)
  AND (JT.ColumnName3 = Y);

Declaración de actualización

UPDATE TargetTable SET
       ColumnName1 = @value,
       ColumnName2 = @value2
 WHERE (Condition1 = @test);

Insertar declaración

INSERT INTO TargetTable 
           (
             ColumnName1,
             ColumnName2,
             ColumnName3
           ) 
           values 
           (
             @value1,
             @value2,
             @value3
           );

Answer 10

Me gusta:

SELECT ST.ColumnName1, JT.ColumnName2, SJT.ColumnName3 --leave all selected columns on the same line
FROM 
    SourceTable ST
INNER JOIN JoinTable JT ON JT.SourceTableID = ST.SourceTableID
INNER JOIN SecondJoinTable SJT --only splitting lines when more than 1 condition
    ON ST.SourceTableID = SJT.SourceTableID
    AND JT.Column3 = SJT.Column4
WHERE
    ST.SourceTableID = X
    and JT.ColumnName3 = Y

para obtener más código en un área de visualización más pequeña. También creo que las palabras clave deben estar en mayúsculas

Answer 11

Mejor tarde que nunca. Utilizo un estilo diferente y lo adopté de un muy buen desarrollador de SQL con el que solía trabajar. Alineo correctamente las palabras clave y utilizo las letras MAYÚSCULAS para facilitar la escritura. Las palabras clave serán resaltadas por el editor y no veo la necesidad de que estén en MAYÚSCULAS a menos que haga mucha edición en editores de texto que no admite funciones de resaltado de palabras clave. No intento que sea compacto, sino más legible y alineado verticalmente tanto como sea posible. Aquí hay un ejemplo de selección tomada de @BenLaan respuesta escrita en mi formato:

select st.ColumnName1
       , jt.ColumnName2
       , sjt.ColumnName3
  from SourceTable st
         inner join
       JoinTable jt
         on jt.SourceTableID = st.SourceTableID
         inner join
       SecondJoinTable sjt
         on st.SourceTableID = sjt.SourceTableID
         and st.SourceTable2ID = sjt.SourceTable2ID
 where st.SourceTableID = X
       and jt.ColumnName3 = Y
       and jt.Column3 = sjt.Column4
 order by st.ColumnName1

Tratar de conformar a todo el equipo para seguir el mismo patrón de formateo es lo más difícil. Seguiría cualquier formato si todos los demás siguieran el mismo camino, pero nunca ha sido la misma historia.

ACTUALIZACIÓN: Reescribiendo una de las consultas complejas mencionadas en publicaciones anteriores:

select
       term
       , student_id
       , case
           when((ft_credits > 0 and credits >= ft_credits) or (ft_hours_per_week > 3 and hours_per_week >= ft_hours_per_week))
             then ''F''
           else ''P''
         end as status
  from (select term
               , student_id
               , pm.credits AS ft_credits
               , pm.hours AS ft_hours_per_week
               , SUM(credits) AS credits
               , SUM(hours_per_week) AS hours_per_week
          from (select e.term
                       , e.student_id
                       , nvl(o.credits, 0) credits
                       , case
                           when nvl(o.weeks, 0) > 5 
                             then (nvl(o.lect_hours, 0) + nvl(o.lab_hours, 0) + nvl(o.ext_hours, 0)) / nvl(o.weeks, 0)
                           else 0
                        end as hours_per_week
                  from enrollment as e
                         inner join 
                       offering as o using (term, offering_id)
                         inner join
                       program_enrollment as pe 
                         on e.student_id = pe.student_id 
                         and e.term = pe.term 
                         and e.offering_id = pe.offering_id
                 where e.registration_code not in (''A7'', ''D0'', ''WL'')
                )
                  inner join 
                student_history as sh using (student_id)
                  inner join 
                program_major as pm 
                  on sh.major_code_1 = pm._major_code and sh.division_code_1 = pm.division_code
         where sh.eff_term = (select max(eff_term)
                                from student_history as shi
                               where sh.student_id = shi.student_id
                                     and shi.eff_term <= term)
         group by term, student_id, pm.credits, pm.hours
        )
 order by term, student_id

Answer 12

Mi estilo preferido:

SELECT
  ST.ColumnName1,
  JT.ColumnName2,
  SJT.ColumnName3
FROM
  SourceTable ST
INNER JOIN
  JoinTable JT
ON
  JT.SourceTableID = ST.SourceTableID
INNER JOIN
  SecondJoinTable SJT
ON
  ST.SourceTableID = SJT.SourceTableID
WHERE
  ST.SourceTableID = X
AND
  JT.ColumnName3 = Y
AND
  JT.Column3 = SJT.Column4

Answer 13

Nadie ha hecho expresiones comunes de tablas (CTE) todavía. A continuación lo incorpora junto con algunos otros estilos que uso:

@declare @tableVariable (
    colA1 int,
    colA2 int,
    colB1 int,
    colB2 nvarchar(255),
    colB3 nvarchar(255),
    colB4 int,
    colB5 bit,
    computed int
);

with

    getSomeData as (

        select        st.colA1, sot.colA2
        from          someTable st
        inner join    someOtherTable sot on st.key = sot.key

    ),

    getSomeOtherData as (

        select        colB1, 
                      colB2, 
                      colB3,
                      colB4,
                      colB5,
                      computed =    case 
                                    when colB5 = 1 then ''here''
                                    when colB5 = 2 then ''there''
                                    end
        from          aThirdTable tt
        inner hash 
         join         aFourthTable ft
                      on tt.key1 = ft.key2
                      and tt.key2 = ft.key2
                      and tt.key3 = ft.key3

    )

    insert      @tableVariable (
                    colA1, colA2, colA2, 
                    colB1, colB2, colB3, colB4, colB5, 
                    computed 
                )
    select      colA1, colA2, 
                colB1, colB2, colB3, colB4, colB5, 
                computed 
    from        getSomeData data1
    join        getSomeOtherData data2

Algunos puntos en el formato CTE:

• En mi CTE "con" está en una línea separada, y todo lo demás en el cte está sangrado.
• Mis nombres de CTE son largos y descriptivos. Los CTE pueden ser complejos y los nombres descriptivos son muy útiles.
• Por alguna razón, me encuentro prefiriendo los verbos para los nombres CTE. Lo hace parecer más animado
• Estilo similar con los paréntesis como Javascript hace con sus llaves. También es así como hago las llaves en C #.

Esto simula:

func getSomeData() {

    select        st.colA1, sot.colA2
    from          someTable st
    inner join    someOtherTable sot on st.key = sot.key

}

Algunos puntos además del formato CTE:

• Dos pestañas después de "seleccionar" y otras palabras clave. Eso deja suficiente espacio para "unión interna", "agrupar por", etc. Puede ver un ejemplo anterior donde eso no es cierto. Pero la "combinación interna de hash" DEBE parecer fea. Sin embargo, en este punto, probablemente voy a experimentar con algunos de los estilos anteriores en el futuro.
• Las palabras clave son minúsculas. Su coloración por el IDE y su estado de indentación especial los resaltan lo suficiente. Me reservo mayúsculas para otras cosas que quiero enfatizar basadas en la lógica local (de negocios).
• Si hay pocas columnas, las pongo en una fila (getSomeData). Si hay algunos más, los verticalizo (getSomeOtherData). Si hay demasiada verticalización en una unidad, horizontalizo algunas columnas en la misma línea agrupada por lógica definida localmente (el segmento final de inserción y selección). Por ejemplo, pondría información de nivel escolar en una línea, nivel de estudiante en otra, etc.
• Especialmente cuando se está verticalizando, prefiero el nombre "varname = colname + something syntax" del servidor sql a "colname + something as varname".
• Duplique el último punto si estoy tratando con una declaración de caso.
• Si cierta lógica se presta a un estilo de ''matriz'', me ocuparé de las consecuencias del tipeo. Eso es más o menos lo que está sucediendo con la declaración del caso, donde los ''whens'' y ''then''s están alineados.

Encuentro que estoy más centrado en mi estilo CTE que en otras áreas. No he experimentado con los estilos más similares a los planteados en la pregunta. Probablemente lo haga algún día y vea cómo me gusta. Probablemente estoy maldito por estar en un ambiente donde es una elección, aunque es una maldición divertida de tener.

Answer 14

Sí, puedo ver el valor de diseñar su sql de una manera rigurosamente definida, pero seguramente la convención de nomenclatura y su intención son mucho más importantes. Como 10 veces más importante.

Basado en que mi mascota odia son las tablas con el prefijo tbl, y los procedimientos almacenados con el prefijo sp - sabemos que son tablas y SP. La denominación de objetos DB es mucho más importante que la cantidad de espacios que hay

Solo mi valor de $ 0.02

Answer 15

Si realizo cambios en T-SQL ya escrito, entonces sigo la convención ya usada (si la hay).

Si estoy escribiendo desde cero o no hay una convención, entonces tiendo a seguir su convención dada en la pregunta, excepto que prefiero usar mayúsculas para las palabras clave (solo una preferencia personal para la legibilidad).

Creo que con el formato SQL como con otras convenciones de formato de código, el punto importante es tener una convención, no lo que esa convención es (¡dentro de los dominios del sentido común, por supuesto!)

Answer 16

Soy de la opinión de que siempre que pueda leer el código fuente fácilmente, el formato es secundario. Siempre que se logre este objetivo, hay una serie de buenos estilos de diseño que pueden adoptarse.

El único otro aspecto que es importante para mí es que sea cual sea el diseño / estilo de codificación que elija adoptar en su tienda, asegúrese de que todos los programadores la utilicen de manera uniforme.

Solo para su referencia, aquí es cómo presentaría el ejemplo que proporcionó, solo mi preferencia de diseño. De particular interés, la cláusula ON está en la misma línea que la unión, solo la condición de unión primaria se enumera en la unión (es decir, la coincidencia de tecla) y otras condiciones se mueven al cluase de donde.

select
    ST.ColumnName1,
    JT.ColumnName2,
    SJT.ColumnName3
from 
    SourceTable ST
inner join JoinTable JT on 
    JT.SourceTableID = ST.SourceTableID
inner join SecondJoinTable SJT on 
    ST.SourceTableID = SJT.SourceTableID
where
        ST.SourceTableID = X
    and JT.ColumnName3 = Y
    and JT.Column3 = SJT.Column4

Un consejo: obtén una copia de SQL Prompt de Red Gate. Puede personalizar la herramienta para usar las preferencias de diseño deseadas y, a continuación, los programadores de su tienda pueden usarla para garantizar que todos adopten los mismos estándares de codificación.

Answer 17

Sugeriría el siguiente estilo, basado en la sugerencia de John:

/*
<Query title>
<Describe the overall intent of the query>
<Development notes, or things to consider when using/interpreting the query>
*/
select
    ST.ColumnName1,
    JT.ColumnName2,
    SJT.ColumnName3
from 

    -- <Comment why this table is used, and why it''s first in the list of joins>
    SourceTable ST

    -- <Comment why this join is made, and why it''s an inner join>
    inner join JoinTable JT
        on ST.SourceTableID = JT.SourceTableID

    -- <Comment why this join is made, and why it''s an left join>
    left join SecondJoinTable SJT
        on  ST.SourceTableID = SJT.SourceTableID
        and JT.Column3 = SJT.Column4

where

    -- comment why this filter is applied
    ST.SourceTableID = X

    -- comment why this filter is applied
    and JT.ColumnName3 = (
            select 
                somecolumn
            from 
                sometable
        )
;

Ventajas:
- Los comentarios son una parte esencial para hacer que el código sea legible y para detectar errores.
- Agregar -todos los filtros "a" a la unión evita errores al cambiar de unión interna a izquierda.
- Colocar el punto y coma en una nueva línea permite añadir / comentar fácilmente las cláusulas where.

Answer 18

Tarde, pero voy a lanzar mi sombrero en el ring. Lleva un poco más de tiempo escribir, pero descubro que surgen patrones con la alineación vertical que lo hacen muy legible una vez que está acostumbrado.

SELECT ST.ColumnName1,
       JT.ColumnName2,
       SJT.ColumnName3,
       CASE WHEN condition1 = True 
             AND condition2 = True Then DoSomething
            Else DoSomethingElse
        END ColumnName4
  FROM SourceTable AS ST
 INNER
  JOIN JoinTable AS JT
    ON JT.SourceTableID = ST.SourceTableID
 INNER
  JOIN SecondJoinTable AS SJT
    ON ST.SourceTableID = SJT.SourceTableID
   AND JT.Column3 = SJT.Column4
  LEFT
  JOIN (SELECT Column5
          FROM Table4
       QUALIFY row_number() OVER
                 ( PARTITION BY pField1,
                                pField2
                       ORDER BY oField1
                 ) = 1
       ) AS subQry
    ON SJT.Column5 = subQry.Column5
 WHERE ST.SourceTableID = X
   AND JT.ColumnName3 = Y

Answer 19

Tiendo a usar un diseño similar al suyo, aunque incluso voy unos pasos más allá, por ejemplo:

select
        ST.ColumnName1
    ,   JT.ColumnName2
    ,   SJT.ColumnName3
from
                SourceTable     ST

    inner join  JoinTable       JT
        on  JT.SourceTableID    =   ST.SourceTableID

    inner join  SecondJoinTable SJT
        on  ST.SourceTableID    =   SJT.SourceTableID

where
        ST.SourceTableID    =   X
    and JT.ColumnName3      =   Y
    and JT.Column3          =   SJT.Column4

Tal vez se vea un poco exagerado al principio, pero en mi humilde opinión, el uso de la tabulación proporciona el diseño más limpio y sistemático dada la naturaleza declarativa de SQL.

Probablemente termines con todo tipo de respuestas aquí, al final depende de las preferencias personales o del equipo acordado.

Answer 20

Utilizo un formato similar al tuyo, excepto que puse la palabra clave "ON" en la misma línea que la unión y puse los operadores "AND" y "OR" al final de las líneas para que todos mis criterios de unión / selección se alineen bien.

Si bien mi estilo es similar al de John Sansom, no estoy de acuerdo con poner criterios de unión en la cláusula WHERE. Creo que debería ser con la tabla unida para que esté organizada y sea fácil de encontrar.

También tiendo a poner paréntesis en líneas nuevas, alineado con la línea de arriba y luego sangrando en la línea siguiente, aunque para las declaraciones cortas puedo mantener los paréntesis en la línea original. Por ejemplo:

SELECT
     my_column
FROM
     My_Table
WHERE
     my_id IN
     (
          SELECT
               my_id
          FROM
               Some_Other_Table
          WHERE
               some_other_column IN (1, 4, 7)
     )

Para las sentencias CASE doy una nueva línea y sangría para cada WHEN y ELSE y alineo el END de nuevo con CASE:

CASE
     WHEN my_column = 1 THEN ''one''
     WHEN my_column = 2 THEN ''two''
     WHEN my_column = 3 THEN ''three''
     WHEN my_column = 4 THEN ''four''
     ELSE ''who knows''
END

Answer 21

Yo uso Red Gate SQL ReFactor dentro de SSMS, pero otra herramienta que hace reformas (y es un reemplazo para SSMS) es Apex''s SQL Edit . Si está buscando publicar código en línea, existe The Simple-Talk SQL Prettifier .

Answer 22

Respuesta tardía pero con suerte útil

Mi experiencia trabajando como parte del equipo de desarrollo más grande es que puedes seguir adelante y definir los estándares que te gusten, pero el problema es hacerlos cumplir o hacer que sea muy fácil de implementar para los desarrolladores.

Como desarrolladores, a veces creamos algo que funciona y luego decimos "Voy a formatearlo más tarde", pero eso luego nunca llega.

Inicialmente usamos SQL Prompt (fue genial) para esto, pero luego cambiamos a ApexSQL Refactor porque es una herramienta gratuita.

Answer 23

Cien respuestas aquí ya, pero después de mucho ir y venir en los últimos años, esto es lo que he decidido por:

SELECT      ST.ColumnName1
          , JT.ColumnName2
          , SJT.ColumnName3

FROM        SourceTable       ST
JOIN        JoinTable         JT  ON  JT.SourceTableID  =  ST.SourceTableID
JOIN        SecondJoinTable  SJT  ON  ST.SourceTableID  =  SJT.SourceTableID
                                  AND JT.Column3        =  SJT.Column4

WHERE       ST.SourceTableID  =  X
AND         JT.ColumnName3    =  Y

Sé que esto puede hacer para ficheros diff desordenado como una mesa adicional podría causar mí para volver a sangrar muchas líneas de código, pero para mi facilitar la lectura, me gusta.

Answer 24

Parece ser que la mayoría de ustedes todavía trabajan en los monitores que sólo soportan 800x600. Mis monitores harán 1920x1080, así que quiero utilizar todo ese espacio a la derecha.

Qué tal esto:

select col1, col2, col3
, case when x = 1 then ''answer1''
       else ''answer2''
  end
, col4, col5, col6, col7
from table1 t1
inner join table2 t2 on t1.col1 = t2.col1 and t1.col2 and t2.col2
where t1.col5 = 19 and t1.col7 = ''Bill Gates''

Answer 25

SELECT
    a.col1                  AS [Column1]
    ,b.col2                 AS [Column2]
    ,c.col1                 AS [Column3]
FROM
    Table1 a
    INNER JOIN Table2 b     ON b.Id = a.bId
    INNER JOIN Table3 c     ON c.Id = a.cId
WHERE
    a.col     = X
    AND b.col = Y

Utiliza muchas más líneas que muchos de los ejemplos aquí, pero creo que es mucho más fácil de entender, permite la eliminación rápida de columnas / cláusulas / tablas. Ayuda a aprovechar un monitor orientado verticalmente.

Answer 26

SELECT st.ColumnName1
      ,jt.ColumnName2
      ,sjt.ColumnName3
FROM   SourceTable st
JOIN   JoinTable jt ON jt.SourceTableID = st.SourceTableID
JOIN   SecondJoinTable sjt ON SstT.SourceTableID = sjt.SourceTableID
                              AND jt.Column3 = sjt.Column4
WHERE  st.SourceTableID = X
       AND jt.ColumnName3 = Y

Yo uso todas las tapas de las palabras acciones, se une o cláusulas, se destacan mejor. JOIN es el mismo que el INNER JOIN por lo interior no necesita ser escrita a cabo, se supone, escribir OUTER JOIN o LEFT JOIN cuando lo necesite. También uso lowere caso de mis nombres de alias. causa común frente a cabo si se comente la última columna que hay que contentarse con una coma arriba y la consulta falla.