Consultas SQL de formatação de código

Devo interromper as consultas SQL em linhas diferentes? Por exemplo, no projeto em que estou trabalhando, temos uma consulta que ocupa 1600 colunas! 1600 + caracteres de tabulação. Eu escrevi consultas como esta:

   "SELECT bla , bla2 , bla FROM bla " . 
     "WHERE bla=333 AND bla=2" . 
      "ORDER BY nfdfsd ...";

Mas eles exigiram que eu os colocasse em uma linha e disseram que meu estilo é de formatação ruim. Por que é uma má prática?

Por motivos de controle de origem, temos quebras de linha após cada cláusula where ou vírgula. Então, o seu acima se transforma

SELECT bla 
     , bla2 
     , bla 
FROM   bla 
WHERE  bla=333 
  AND  bla=2
ORDER  BY nfdfsd
        , asdlfk;

(tabulação e alinhamento não têm padrão aqui, mas vírgulas geralmente são iniciais)

Ainda assim, não faz diferença no desempenho.

Uma consulta com 1600 colunas parece precisar de uma revisão séria por um bom DBA.

Se uma consulta for complexa, eu a envolverei. Se for direto, deixarei como uma única linha, a menos que demore muito, então começarei a envolvê-la novamente.

É tudo sobre gerenciamento e compreender o que é suposto fazer para que o agrupamento ou não do agrupamento possa ser decidido em tempo real, a menos que sua organização tenha algumas regras de formatação de código.

Re: sendo uma má prática de codificação. Dificilmente! É uma prática muito boa. Sei que não existem boas razões para usar uma consulta por muito tempo e muitas boas razões para reformatá-la. Como eu disse antes, um DBA qualificado provavelmente precisa trabalhar nele.

A única vantagem das consultas de linha única que vem à mente é que essas consultas podem ser um pouco mais fáceis de serem cumpridas. Fora isso, porém, estou perplexo. Pessoalmente, prefiro as consultas mais legíveis e divididas.

Os comentários de várias linhas são bons, quase vitais ao lidar com grandes volumes de SQL. E se sua linguagem de programação possui citações heredoc, é ainda melhor (como muitos editores podem destacar a sintaxe SQL).

Exemplo:

$a = SQL<<<
    SELECT a, b, c, d
    FROM Foo f
    WHERE f.a = ?
SQL;

Ao trabalhar com consultas de dezenas de linhas (ou centenas), o recuo e o espaço em branco tornam o texto viável.

Parece que isso é especificamente sobre definir uma grande consulta dentro de uma espécie de linguagem de programação, vendo você colocar a consulta dentro de uma string literal e concatená-la.

Se é uma linguagem compilada, não deve fazer diferença alguma - uma das primeiras otimizações que o compilador faria é concatenar automaticamente os literais das strings, para que você acabe com uma string grande de qualquer maneira.

Quanto à sintaxe, você deve considerar mover a consulta para fora do seu código - armazene-a em um arquivo de recurso .sql separado e faça com que seu software leia esse arquivo. Use instruções preparadas para as variáveis, se não for uma consulta criada dinamicamente (por exemplo, cláusulas where etc. adicionadas dependendo de determinados parâmetros). Se ele for construído dinamicamente, você poderá adicionar suas próprias variáveis ​​de substituição, inserindo parâmetros extras onde e quando necessário.

Quanto às 1600 colunas, recomendo seriamente criar uma exibição para isso, então, em vez de

SELECT column1, column2, .... column1600 from X where Y

você conseguiria

SELECIONE * DO viewX ONDE y

Muito mais conciso em seu próprio código.

Costumo usar o formato apresentado por @glasnt para solucionar problemas de uma consulta complicada, mas geralmente tenho consultas em uma única linha.

Isso pode não responder à sua pergunta, mas eu também sugiro dividir sua consulta em consultas menores. Obviamente, isso depende da consulta, mas quanto mais cláusulas e associações você adicionar à sua consulta - menos o mecanismo SQL poderá otimizar sua consulta.

O fornecedor do seu banco de dados deve ter ferramentas como a EXPLAIN do MySQL (ou a configuração SHOWPLAN_ALL do MSSQL), que mostrará o que o banco de dados está fazendo nos bastidores para otimizar sua consulta, toda vez que o banco de dados precisar criar uma tabela temporária ou algo parecido, você está adicionando grandes atrasos quando você está falando sobre vários usuários simultâneos.

Movendo o que pode parecer uma lógica trivial para fora do SQL e para o seu código, você pode fornecer aumentos drásticos no desempenho - o SQL é ótimo em operações simples.

O benefício óbvio para isso, como pode estar relacionado a você, é que suas consultas são muito menos complexas e fáceis de ler - fáceis de gerenciar (não> 1600 colunas) e mais rápidas. Definitivamente uma vitória geral.

Espero que isto ajude :)