Tips for writing SQL

Introdução

Esta página contém dicas e truques para escrever transformações SQL.

Geral

• Em uniões, os nomes e a ordem dos campos devem corresponder exatamente. Pode ser necessário criar campos vazios em partes da união para alinhar todos os campos, com a select instrução null as `Field_X`. Dependendo do dialeto SQL, você pode precisar usar null as "Field_X".
• Ao escrever dbt para SQL Server, todas as instruções Jinja são compiladas em código SQL, independentemente de estarem dentro de comentários SQL ou não. Por exemplo, no seguinte -- {{ ref('Table1') }}, o Jinja será compilado no código SQL.
• Não arredonde os números, isso pode levar a inconsistências. A plataforma fará isso automaticamente sempre que um valor de exibição exigir isso.

Estrutura de Transformação

Em SQL, nem todas as transformações podem ser calculadas na mesma tabela. A razão para isso pode ser agregados ou propriedades que não podem ser expressas em uma única declaração SELECT. Crie tabelas auxiliares para esse fim. A criação de uma tabela auxiliar no banco de dados permite usar o modelo em várias transformações. Se não for necessário reutilizar o modelo, a transformação auxiliar também pode ser adicionada como uma consulta de pré-processamento na tabela existente.

Para fazer uma distinção entre as transformações de suporte e as outras transformações, você pode agrupá-las em um subdiretório separado.

Desempenho

Para tornar a execução da consulta mais rápida:

• Evite select distinct onde também é possível construir um agregado e apenas obter um registro usando uma cláusula where .
• Use union all em vez de union. Usando union all, os registros das tabelas são concatenados, enquanto union remove duplicatas.
• Se você estiver trabalhando em um grande conjunto de dados, poderá limitar os dados com os quais está trabalhando durante o desenvolvimento.
• Todos os modelos (exceto os modelos no diretório 1_input ) são materializados como uma tabela por dbt. Esta é a configuração padrão para todos os Conectores do Process Mining. Para obter mais informações, consulte a documentação do dbt em Materializações.
• Ao gerar um campo id, use a macro id() disponível em pm-utils. Exemplos podem ser encontrados no devkit-connector.

Guia de estilo SQL

O seguinte guia de estilo foi usado para desenvolver os modelos de aplicativos do Process Mining . Recomendamos seguir estas diretrizes para obter consistência e legibilidade.

• Escreva comandos e funções SQL em letras minúsculas.
• Use o mesmo nível de recuo para select,  from,  where, join, etc., para entender a estrutura do modelo com mais facilidade.
  • Use o recuo para o uso de funções se melhorar a legibilidade. Por exemplo, use o recuo para cada instrução em uma função case.

• Use convenções de nomenclatura consistentes para tabelas e campos para evitar erros de SQL indicando que tabelas ou campos não existem no banco de dados. Siga as seguintes orientações:

  • Tabelas e campos começam com maiúscula.
  • Use um sublinhado _ entre palavras separadas em tabelas e campos.
  • Todos os campos têm aspas.
  • As tabelas não possuem aspas. Isso melhora a legibilidade em combinação com campos com aspas.
• Todos os campos são prefixados com a tabela de origem, para facilitar a compreensão e extensão do modelo.
• As vírgulas utilizadas para a separação dos campos são colocadas no final da linha.
• Use comentários embutidos quando certas construções precisam ser explicadas. Quando isso for feito, verifique se o comentário agrega valor.
• Para legibilidade e manutenção, use instruções de seleção explícitas na parte de transformação da consulta e não use select *. Especialmente para uniões, usar o select * pode gerar erros.