Padrões de formatação SQL
para cobrir a pesquisa principal tipos:
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
Houve um desentendimento sobre as linhas de transmissão depois select
, from
e where
A intenção na linha selecionada é permitir que outros operadores como" top X " sem alterar o layout. Seguindo a partir daí, simplesmente mantendo uma linha consistente feed após os elementos de consulta chave parecia resultar em um bom nível de legibilidade.
largar a linha após from
e {[5] } seria uma revisão compreensível. No entanto, em consultas como o update
abaixo, vemos que a linha de alimentação depois do where
nos dá um bom alinhamento de colunas. Da mesma forma, uma linha após group by
ou order by
mantém as nossas colunas claras e fáceis de ler.
update
TargetTable
set
ColumnName1 = @value,
ColumnName2 = @value2
where
Condition1 = @test
finalmente, um insert
:
insert into TargetTable (
ColumnName1,
ColumnName2,
ColumnName3
) values (
@value1,
@value2,
@value3
)
na maioria das vezes, estes não se desviam muito da forma como o MS SQL Server Managements Studio / query analyser escreve SQL, no entanto eles do diferem.
Estou ansioso para ver se há algum consenso na comunidade de Stack Overflow em tema. Estou constantemente espantado com quantos desenvolvedores podem seguir a formatação padrão para outras línguas e, de repente, ir tão aleatório ao bater SQL.27 answers
Eu sou da opinião que desde que você possa ler o código fonte facilmente, a formatação é secundária. Enquanto esse objetivo for alcançado, há uma série de estilos de layout bons que podem ser adotados.
O único outro aspecto que é importante para mim é que seja qual for o layout/estilo de codificação que você escolher adotar em sua loja, certifique-se de que ele é consistentemente usado por todos os codificadores.
Só para sua referência, aqui está como eu iria apresentar o exemplo que você forneceu, apenas o meu layout preferência. De uma nota particular, a cláusula ON
está na mesma linha que a join
, apenas a condição de junção primária está listada na junção (ou seja, a correspondência da chave) e outras condições são movidas para a cláusula where
.
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
Uma dica, arranja uma cópia de Prompt SQL de Red Gate . Você pode personalizar a ferramenta para usar as preferências de layout desejadas, e então os programadores em sua loja podem usá-la para garantir que os mesmos padrões de codificação estão sendo adotados por todos.
resposta tardia, mas espero ser útil.
A minha experiência de trabalhar como parte da equipa de desenvolvimento maior é que você pode ir em frente e definir os padrões que quiser, mas o problema é realmente fazer cumprir estes ou torná-lo muito fácil para os desenvolvedores de implementar.
Como desenvolvedores, às vezes criamos algo que funciona e então dizemos "Eu vou formatá-lo mais tarde", mas que mais tarde nunca vem.
Inicialmente, usámos o Prompt SQL (era óptimo) para isto, mas depois mudou para o Refator ApexSQL , porque é uma ferramenta livre.
SELECT
declaração:
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
Em resumo: indentação de 8 espaços, palavras-chave em maiúsculas( embora assim as cores melhor quando em minúsculas), sem camelcase (sem sentido no oráculo), e linha envolve quando necessário.
UPDATE
:
UPDATE target_table
SET column_name_1 = @value,
column_name_2 = @value2
WHERE condition_1 = @test
E o INSERT
:
INSERT INTO target_table (column_name_1, column_name_2,
column_name_3)
VALUES (@value1, @value2, @value3)
Agora, deixe-me ser o primeiro a admitir que este estilo tem problemas. O travessão de 8 espaços significa que ORDER BY
e {[8] } ou desequilibram o travessão, ou dividem a palavra BY
por si só. Também seria mais natural indentar todo o predicado da Cláusula WHERE
, mas eu normalmente alinho seguindo AND
e OR
operadores na margem esquerda. Indentar após as linhas embrulhadas INNER JOIN
também é um pouco arbitrário.
Mas por qualquer razão, ainda acho mais fácil ler do que as alternativas.
Vou acabar com um dos meus mais. criações complexas de tarde usando este estilo de formatação. Praticamente tudo o que encontrarias numa declaração aparece nesta. (Ele também foi alterado para disfarçar suas origens, e eu posso ter introduzido erros ao fazê-lo.)
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 abominação calcula se um estudante é a tempo inteiro ou a tempo parcial num determinado período. Independentemente do estilo, este é difícil de ler.
Linhas novas após select
, from
e where
só quando é necessário para a legibilidade.
Quando o código pode ser mais compacto e igualmente legível, normalmente prefiro a forma mais compacta. Ser capaz de encaixar mais código em um screenful melhora a produtividade.
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
Em última análise, esta será uma decisão que será tomada durante a revisão do Código.
Para insert
, eu colocaria o parêntesis diferentemente:
insert into TargetTable (
ColumnName1,
ColumnName2,
ColumnName3)
values (
@value1,
@value2,
@value3)
O raciocínio para esta formatação é que se SQL usou indentação para a estrutura de blocos (como Python), o parêntesis não seria necessário. Então, se a indentação é usada de qualquer maneira, então parênteses devem ter o efeito mínimo sobre o layout. Isto é conseguido colocando-os no final das linhas.
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
Usa muito mais linhas do que muitos dos exemplos aqui, mas eu sinto que é muito mais fácil de entender, permite a remoção rápida de colunas/cláusulas/tabelas. Ajuda a tirar partido de um monitor verticalmente orientado.
/*
<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
)
;
Vantagens:
- Os comentários são uma parte essencial para tornar o código legível e detectar erros.
- Adicionar todos os filtros " on " à junção evita erros ao mudar da junção interna para a esquerda.
- Colocar o ponto-e-vírgula Em uma nova linha permite fácil adição / comentário de onde as cláusulas.
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
Uso um formato semelhante ao seu, excepto que coloquei a palavra-chave ON
na mesma linha que a junção e coloquei os operadores AND
e OR
no fim das linhas, para que todos os meus critérios de adesão/selecção se alinhem bem.
Também tenho tendência a colocar parêntesis em linhas novas, alinhadas com a linha acima e, em seguida, indentando na próxima linha, embora para declarações curtas, eu posso apenas manter os parênteses na linha original. Por exemplo:
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 CASE
declarações, eu dou uma nova linha e de avanço para cada WHEN
e ELSE
, e eu alinhar o END
de volta para o 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
Estou a trabalhar na escrita de um formatador SQL de código aberto (SQL-Server-apenas nesta fase) em C#, por isso coloquei as consultas acima através dele.
([2]) emprega uma estratégia semelhante à do PO, a saber, que cada "secção" tem elementos-filhos indentados por baixo dele. Quando necessário, eu adiciono espaço branco entre as seções para ajudar a clareza – estas não seriam adicionados quando não há junções ou mínimos onde as condições.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
Sei que estou muito atrasado para este debate, mas gostaria de dar os meus pensamentos. Sou decididamente a favor das vírgulas no início da linha. Como você diz Adam Ralph, é mais fácil comentar um campo e eu também acho que é mais difícil perder uma vírgula acidentalmente quando eles estão no início, enquanto isso não parece uma questão importante. Passei horas no passado a tentar localizar erros de sintaxe acidentais em longos procedimentos T-SQL, onde acidentalmente perdeu uma vírgula no final da linha (tenho certeza de que alguns de vocês provavelmente fizeram isso também). Também sou a favor de alias o máximo possível.
No geral, no entanto, percebo que tudo se deve à preferência pessoal, o que funciona para uns não funciona para outros. Desde que você possa ler o código facilmente e cada desenvolvedor mostra alguma consistência em seu estilo durante todo, eu acho que isso é o mais importante.Costumo usar um layout semelhante ao seu, embora vá mais longe, por exemplo:
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
{[[2]} talvez pareça um pouco exagerado no início, mas IMHO o uso de tabulação deste modo dá o layout mais limpo, mais sistemático dada a natureza declarativa de SQL.
Provavelmente vais acabar com todo o tipo de respostas aqui. No final, depende das preferências pessoais ou de equipa.
Se estou a fazer alterações a T-SQL já escrito, então sigo a Convenção já usada (se houver uma).
Se eu estou escrevendo do zero ou não há Convenção, então eu tendem a seguir a sua convenção dada na pergunta, exceto que eu prefiro usar letras maiúsculas para palavras-chave (apenas uma preferência pessoal para legibilidade).
Eu acho que com a formatação SQL como com outras convenções de formato de código, o importante é ter uma convenção, não o que essa convenção é (dentro dos domínios do senso comum, é claro!)
Só os meus $0.02 worths
Eu uso o ReFactor SQL do Portão Vermelho dentro do SSMS, mas outra ferramenta que faz a reforma (e é um substituto do SSMS)é A edição SQL do Apex . Se você está olhando para postar código on-line há o Prettifier SQL simples .
Eu gosto:
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 obter mais código numa área de visualização mais pequena.
Eu também acredito que palavras-chave devem estar em maiúsculas
Select column1
,column2
,column3
,column4
,Column5 ...ect
Contra:
Select column1,
column2,
column3, ect...
A razão pela qual eu prefiro esta prática é porque, se necessário, você pode comentar uma linha e não haverá um problema de vírgula Quando você executá-lo por conta da vírgula correspondente sendo comentado também. Eu sei que vi outro utilizador no tópico que eu tinha feito isso também, mas realmente não apontá-lo. Não é uma grande revelação para trazer à conversa, mas a minha opinião. Obrigado.
Ainda ninguém acabou as expressões comuns da tabela (Eti). Abaixo incorpora-o juntamente com alguns outros estilos que eu 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
Alguns pontos no formato CTE:
- no meu Eti " com " está numa linha separada, e tudo o resto no ETI está indentado. Os meus nomes de CTE são longos e descritivos. CTE pode obter nomes complexos e descritivos são muito úteis. Por alguma razão, Prefiro verbos para nomes CTE. Faz com que pareça mais animado.
- estilo semelhante com os parênteses como o Javascript faz com os seus suspensórios. É também Como faço os aparelhos em C#.
Isto simula:
func getSomeData() {
select st.colA1, sot.colA2
from someTable st
inner join someOtherTable sot on st.key = sot.key
}
Alguns pontos para além do formato CTE:
- Duas Páginas após" seleccionar " e outras palavras-chave. Isso deixa espaço suficiente para" junção interior"," grupo por", etc. Você pode ver um exemplo acima onde isso não é verdade. Mas "entrada de haxixe interior" deve parecer feio. No entanto, neste ponto eu provavelmente vou experimentar com alguns dos estilos acima no futuro.
- palavras-chave são minúsculas. A sua coloração PELA IDE e o seu estado de indentação especial destacam-nos o suficiente. Reservo maiúsculas para outras coisas que quero enfatizar com base na lógica local (empresarial). Se há poucas colunas, ponho-as numa fila (getSomeData). Se houver mais alguns, eu os verticalizo (obter alguns outros dados). Se houver muita verticalização em uma unidade, eu horizontalizo algumas colunas na mesma linha agrupada por lógica definida localmente (o segmento final insert-select). Por exemplo, eu colocaria informações de nível escolar em uma linha, nível de estudante em outra, etc.
- especialmente quando se verticaliza, Prefiro "varname = colname + something syntax" do servidor sql a "colname + something as varname". Duplica o último ponto se estou a lidar com um caso.
- Se uma certa lógica se presta a um estilo "matrix", eu vou lidar com as consequências de Digitação. Isso é ... mais ou menos o que está acontecendo com a declaração do caso, onde os 'quando' e 'então estão alinhados.
Muito parecido com o facto de usar uma pequena indentação (4). I go with (3).
Nix os Termos 'interior' e 'exterior' como então são desnecessários.
Aqui está como teria formatado a sua declaração de selecção:
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
;
Obrigado por discutir isto.
Gosto que o meu SQL seja formatado assim, embora desde que a intenção seja facilmente legível, a maioria dos formatos funcionará. Eu só realmente odeio ver declarações criadas no designer de consulta e, em seguida, sair dessa maneira. Se estiver a editar outra pessoa, procedure/view / function / trigger, etc.., Eu vou tentar manter a formatação já usada (a menos que seja realmente ruim, então eu vou reformatar a coisa toda).
Seleccionar A Instrução
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);
Declaração De Actualização
UPDATE TargetTable SET
ColumnName1 = @value,
ColumnName2 = @value2
WHERE (Condition1 = @test);
Inserir Declaração
INSERT INTO TargetTable
(
ColumnName1,
ColumnName2,
ColumnName3
)
values
(
@value1,
@value2,
@value3
);
- torna o teu código mais fácil de ler e entender
- minimizar o esforço necessário para manter ou alargar o seu código
- reduzir a necessidade de utilizadores e programadores de um sistema consultarem o secondary fontes de documentação, tais como comentários de código ou manuais de software
Algumas regras que uso sempre:
- utilizar sempre . Notação
- usa sempre um nome falso antes da coluna, por isso . Notação
- pus
and
eor
no fim da linha - não utilize parêntesis rectos desnecessários
- não utilize maiúsculas
- normalmente prefere o cte a sub-séries aninhadas
Como exemplo, aqui como eu formataria a consulta usada como exemplo nesta Pergunta:
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
E "students" query:
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
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
Manter a indentação de 8 caracteres é a chave para a legibilidade do IMHO.
O meu 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
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
Eu uso todas as maiúsculas para as palavras de Acção, para as juntas ou para as cláusulas, elas destacam-se melhor. JOIN é o mesmo que join interior para que o interior não precisa ser escrito para fora, assume-se, escrever JOIN exterior ou junção esquerda quando você precisa. Também uso o caso lowere para os meus nomes falsos. Common out front cause if you comment out the last column you are stuck with a vírma above and the query fails.
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
Sei que isto pode causar confusão, pois uma mesa extra pode fazer-me voltar a indentar muitas linhas de código, mas, para a minha facilidade de leitura, gosto.
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
Tentar conformar toda a equipa para seguir o mesmo padrão de formatação é a coisa mais difícil. Eu seguiria qualquer formato, se todos seguissem o mesmo caminho, mas nunca foi a mesma história.
Actualizar: Reescrever uma das perguntas complexas mencionadas em posts 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
Este é o formato que eu uso. Por favor, comente se pode melhorar.
CREATE PROCEDURE [dbo].[USP_GetAllPostBookmarksByUserId]
@id INT,
@startIndex INT,
@endIndex INT
AS
BEGIN
SET NOCOUNT ON
SELECT *
FROM
( SELECT ROW_NUMBER() OVER ( ORDER BY P.created_date ) AS row_num, P.post_id, P.title, P.points, p.estimated_read_time, P.view_count, COUNT(1) AS "total_attempts" -- todo
FROM [dbo].[BOOKMARKED] B
INNER JOIN [dbo].[POST] P
ON B.entity_id = P.post_id
INNER JOIN [dbo].[ATTEMPTED] A
ON A.entity_id = P.post_id
WHERE B.user_id = 1 AND P.is_active = 1
GROUP BY P.post_id, P.title, P.points, p.estimated_read_time, P.view_count
) AS PaginatedResult
WHERE row_num >= @startIndex
AND row_num < @endIndex
ORDER BY row_num
END
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'