Tips for writing SQL

Introducción

Esta página contiene consejos y trucos para escribir transformaciones de SQL.

General

• En las uniones, los nombres y el orden de los campos deben coincidir exactamente. Puede ser necesario crear campos vacíos en partes de la unión para alinear todos los campos, con la select instrucción null as `Field_X`. Dependiendo del dialecto SQL, es posible que debas usar null as "Field_X".
• Al escribir dbt para SQL Server, todas las declaraciones de Jinja se compilan en código SQL, independientemente de si están dentro de comentarios SQL o no. Por ejemplo, en el siguiente -- {{ ref('Table1') }}, el Jinja se compilará en código SQL.
• No redondee los números, esto puede dar lugar a inconsistencias. La plataforma lo hará automáticamente siempre que un valor de visualización lo requiera.

Estructura de transformación

En SQL, no todas las transformaciones pueden calcularse en la misma tabla. Esto puede deberse a agregados o propiedades que no pueden expresarse en una sola sentencia de selección. Para ello se pueden crear tablas de apoyo. Crear una tabla de apoyo en la base de datos permite utilizar el modelo en múltiples transformaciones. Si no es necesario reutilizar el modelo, la transformación de apoyo también puede añadirse como consulta de preprocesamiento en la tabla existente.

Para hacer una distinción entre las transformaciones compatibles y las otras transformaciones, puedes agruparlas en un subdirectorio independiente.

Rendimiento

Para hacer que la ejecución de su consulta sea más rápida:

• Evite select distinct donde también es posible crear un agregado y solo tomar un registro con una cláusula where .
• Utilice union all en lugar de union. Usando union all, los registros de las tablas se concatenan, mientras que union elimina los duplicados.
• Si trabajas en un gran conjunto de datos, puedes limitar los datos con los que trabajas durante el desarrollo.
• Todos los modelos (excepto los modelos en el directorio 1_input ) se materializan como una tabla por dbt. Esta es la configuración predeterminada para todos los conectores de Process Mining. Para obtener más información, consulta la documentación de dbt sobre Materializaciones.
• Al generar un campo de ID, utiliza la macro id() disponible en pm-utils. Se pueden encontrar ejemplos en devkit-connector.

Guía de estilo SQL

La siguiente guía de estilo se utilizó para desarrollar las plantillas de la aplicación Process Mining . Se recomienda seguir estas directrices para mantener la coherencia y la legibilidad.

• Escribir comandos y funciones SQL en minúsculas.
• Utiliza el mismo nivel de sangría para select  from,  where, join, etc., para comprender más fácilmente la estructura del modelo.
  • Utiliza sangría para el uso de funciones si esto mejora la legibilidad. Por ejemplo, utiliza la sangría para cada sentencia de una función case.

• Utiliza convenciones de nomenclatura coherentes para tablas y campos para evitar errores de SQL que indiquen que las tablas o los campos no existen en la base de datos. Siga las siguientes pautas:

  • Las tablas y los campos comienzan con mayúscula.
  • Utiliza un guion bajo _ entre palabras separadas en tablas y campos.
  • Todos los campos tienen comillas.
  • Las tablas no tienen comillas. Esto mejora la legibilidad en combinación con los campos que tienen comillas.
• Todos los campos tienen el prefijo de la tabla en la que se originan, para facilitar la comprensión y la ampliación del modelo.
• Las comas utilizadas para la separación de campos se colocan al final de la línea.
• Use comentarios en línea cuando necesite explicar ciertas construcciones. Una vez hecho esto, asegúrese de que el comentario agregue valor.
• Para facilitar la lectura y el mantenimiento, usa instrucciones seleccionar explícitas en la parte de transformación de la consulta y no uses select *. Especialmente para las uniones, el uso de select * puede producir errores.