Las herramientas de transformación modernas (dbt, SQLMesh, Dataform) permiten escribir SQL con templating. Podés usar variables, condicionales, loops y funciones reutilizables. En dbt se llama Jinja y macros. En otras herramientas hay mecanismos equivalentes.
Esa capacidad resuelve problemas reales: evitar repetir lógica, parametrizar comportamiento según el entorno, generar código dinámicamente cuando el patrón es el mismo pero los nombres cambian. Pero como cualquier código, puede escribirse bien o puede escribirse mal.
Qué habilita el templating
Cuando escribís transformaciones, hay patrones que se repiten. Calcular un hash de varias columnas. Aplicar la misma lógica de limpieza a múltiples campos. Generar columnas de auditoría. Manejar diferencias entre entornos de desarrollo y producción.
Sin templating, terminás copiando y pegando. Y copiar y pegar es la forma más rápida de introducir inconsistencias: cambiás la lógica en un lugar, te olvidás de otro, y ahora tenés dos versiones que deberían ser iguales pero no lo son.
El templating te permite definir la lógica una vez y reutilizarla. Si mañana cambia el criterio, lo cambiás en un lugar y se propaga a todos los modelos que lo usan.
También permite parametrizar. Podés tener un modelo que se comporte distinto según una variable: filtrar por fecha, apuntar a un schema diferente, activar o desactivar una rama de lógica. Eso habilita cosas como correr el mismo código en desarrollo con un subset de datos y en producción con el dataset completo.
El templating es código
Acá está el punto que a veces se pierde: el templating es código. No es configuración, no es metadata, es código que genera código. Y como cualquier código, aplican las mismas reglas de calidad que aprendiste en programación.
Si escribís una función en Python, le ponés un nombre que diga qué hace. Si la función hace demasiadas cosas, la partís. Si tenés una catarata de ifs anidados, buscás otra forma de estructurarlo. Esas reglas no desaparecen porque estés escribiendo Jinja en lugar de Python.
Cuando leés un modelo con templating, deberías poder entender qué va a generar sin necesidad de ejecutarlo. No el SQL exacto línea por línea, pero sí la estructura general: qué tablas va a leer, qué columnas va a producir, qué lógica va a aplicar. Si no podés, el código está mal escrito.
Reglas que siguen aplicando
Nombres que dicen qué hace la macro. Si tenés una macro que se llama process_data, no dice nada. Si se llama hash_columns o add_audit_timestamps, sabés qué esperar. El nombre es documentación.
Una macro hace una cosa bien. Si tu macro calcula un hash, aplica una transformación de fechas, y además maneja un caso especial de nulos, está haciendo demasiado. Partila en macros más chicas que se puedan componer.
Evitar cataratas de ifs. Si tu modelo tiene cinco niveles de {% if %} anidados, es difícil de seguir. Buscá otra estructura: macros separadas para cada caso, variables intermedias que simplifiquen las condiciones, o replantear si realmente necesitás tanta lógica condicional.
Limitar los niveles de indirección. Una macro que llama a otra macro está bien. Una macro que llama a otra que llama a otra que llama a otra es difícil de seguir. Cada nivel de indirección es un salto mental que alguien tiene que hacer para entender qué pasa.
Señales de que el código está mal escrito
Necesitás ejecutar para entender. Si para saber qué columnas va a tener una tabla tenés que correr el modelo y mirar el resultado, el código no está comunicando lo que hace.
Los errores son imposibles de rastrear. Cuando algo falla y no podés conectar el error con una parte específica del código fuente, probablemente haya demasiada indirección o lógica oculta en macros.
Solo una persona entiende cómo funciona. Si el resto del equipo usa las macros como cajas negras porque nadie más entiende qué hacen, tenés un problema. El código debería ser legible para cualquiera del equipo, no solo para quien lo escribió.
Más Jinja que SQL. Si la mayor parte del archivo son condicionales, loops y llamadas a macros, y el SQL real está enterrado entre llaves y porcentajes, el balance está mal. El SQL debería ser el protagonista; el templating es soporte.
Cuándo vale la pena abstraer
La abstracción tiene sentido cuando el patrón se repite muchas veces y es estable. Si tenés 50 modelos que calculan un hash de la misma manera, una macro tiene sentido. Si lo hacés en 3 modelos, probablemente sea más claro tener el código explícito.
También importa si el equipo entiende el mecanismo. Una macro bien nombrada que hace una cosa clara es fácil de adoptar. Una macro genérica que hace muchas cosas según parámetros es difícil de usar correctamente.
En resumen
El templating en transformaciones resuelve problemas reales de repetición y parametrización. Pero es código, y como código, aplican las mismas reglas de calidad de siempre.
Nombres claros. Funciones que hacen una cosa. Evitar anidamiento excesivo. Limitar la indirección. Si seguís esas reglas, vas a poder leer el código y entender qué va a generar. Si no las seguís, vas a terminar con un revoltijo que nadie entiende, incluyéndote a vos en seis meses.