Basics — Fundamentos de SQL en Marketing Cloud | Cleon

SQL en Marketing Cloud es lo que usás cuando los Filter Activities y la segmentación drag-and-drop no alcanzan. Vive en Automation Studio, corre como una SQL Query Activity, y escribe el resultado en un Data Extension que vos apuntás. Esa es la superficie completa — no hay consola SQL ad-hoc, no hay psql, no hay tooling de backup.

Esta página es la orientación. El resto del catálogo SQL (cláusulas, funciones, style) se construye sobre este modelo mental.

Sintaxis oficial

Cada SQL Query Activity tiene la misma forma: un SELECT (con FROM, JOIN, WHERE, GROUP BY, etc., opcionales) que produce filas, más un Data Extension de destino configurado que las recibe. Vos no escribís el INSERT INTO — Automation Studio lo escribe por vos, basado en el DE de destino que elegiste y la target action (Overwrite, Append, Update) que configuraste.

-- Esta es toda la query que escribís en la Activity:
SELECT
  s.SubscriberKey,
  s.EmailAddress,
  s.LoyaltyTier
FROM master_subscribers s
WHERE s.Status = 'Active';

-- La Activity la envuelve como:
--   INSERT INTO <destination_de>
--   <tu SELECT de arriba>
-- con el comportamiento de merge definido por la target action de la Activity.

La sintaxis soportada es un subset estricto de T-SQL:

Proyección con SELECT con aliases de columna, expresiones y funciones a nivel columna ✓
FROM Data Extensions y System Data Views ✓
WHERE, GROUP BY, HAVING, ORDER BY (con asteriscos) ✓
Joins INNER, LEFT, RIGHT, FULL OUTER ✓
CASE, LIKE, IN, IS NULL ✓
Funciones comunes: COUNT, SUM, AVG, MIN, MAX, DATEADD, DATEDIFF, LEN, LEFT, RIGHT, LOWER, UPPER, REPLACE, CAST, CONVERT, ISNULL, COALESCE ✓
INSERT, UPDATE, DELETE, MERGE como statements standalone ✗ — solo INSERT INTO ... SELECT vía el wrapper de la Activity
CREATE, ALTER, DROP ✗
Stored procedures, triggers, views ✗
Transacciones (BEGIN TRAN / COMMIT / ROLLBACK) ✗
Window functions, CTEs — depende de la edición (ver gotchas — #4)

Referencia:

Lo que sobrevive en producción

El DE de destino define todo

El SELECT que escribís NO define el destino. El Data Extension de destino sí — nombres de columnas, tipos, longitudes, primary key, retention. Tu SELECT produce filas; el destino decide qué entra y qué se trunca, se descarta o se mergea.

[ SELECT ] → filas (proyección sin tipo)
        ↓
[ DE de destino ]
   - Los nombres de columnas tienen que matchear (case-insensitive)
   - Los tipos se coercen al tipo del destino
   - Los largos truncan en silencio si el SELECT es más ancho
   - La primary key controla el merge en modo Update
   - El setting de retention controla el auto-borrado

Si los nombres de tu SELECT no matchean las columnas del DE de destino, la Activity falla en voz alta. Si los tipos o largos no matchean, anda exitosamente y corrompe tus datos en silencio. Ver gotchas — #5.

Elegí la target action antes de escribir la query

La Activity tiene tres target actions; elegí antes de escribir una línea de SQL porque cada una implica una forma de query distinta:

Overwrite — el DE de destino se vacía, después se insertan las filas del SELECT. Usalo para rebuilds completos.
Append — las filas del SELECT se agregan a lo que ya estaba. Sin deduplicación; los duplicados son tu problema.
Update — las filas matchean contra la primary key del DE de destino y se mergean. Las filas existentes ven sus columnas no-key sobreescritas por los valores del SELECT; las filas nuevas se insertan. Requiere que el DE de destino tenga primary key configurada.

Un SELECT TOP 100 tiene sentido en Overwrite (querés exactamente esas 100 filas en el destino); la misma query en Append te deja con 100 nuevos duplicados cada corrida. Mismo SQL, resultados opuestos.

Dónde viven las SQL Activities y cómo corren

Las SQL Query Activities no existen aisladas — viven dentro de una Automation en Automation Studio. Una Automation puede ser:

Scheduled — corre con cadencia fija (cada hora, cada martes, etc.).
Triggered — corre cuando un archivo aterriza en una carpeta de Enhanced FTP (file drop trigger).
Run once — disparada manualmente, útil para migraciones y fixes one-shot.

Una sola Automation puede encadenar múltiples Activities — típicamente: SQL Query → Verificación → Send Email → Log a DE. Cada Activity es independiente; si el paso 2 falla, las escrituras del paso 1 ya están commiteadas (sin transacciones, ver gotchas — #1).

Decisión rápida

Andá con SQL Query Activity cuando:

Necesitás combinar datos de múltiples Data Extensions (joins).
Necesitás transformar valores (lógica de case, math de fechas, normalización de strings).
Necesitás deduplicar, segmentar o agregar datos hacia un DE de destino.
La query se beneficia de ser scheduleada o triggereada (no ad-hoc).

Andá con Filter Activity cuando:

Solo necesitás un WHERE contra un solo Data Extension y el destino es también un solo DE.
La audiencia es lo suficientemente chica como para que el builder visual sea más rápido que escribir SQL.
Stakeholders no técnicos necesitan mantenerla.

Andá con AMPscript o SSJS cuando:

La transformación es por mensaje (personalización al momento del send).
El dato vive afuera de MC y necesita un callout para traerlo.
Necesitás control flow que SQL no expresa (loops, sends condicionales).

No uses SQL Query Activity cuando:

Lo que querés es borrar o alterar filas in-place — MC SQL no puede.
Necesitás una transacción a través de múltiples escrituras — MC SQL no puede.
Estás bajo una ventana de 30 minutos con joins de millones de filas en un tenant ocupado — partilo en Activities por etapas primero.

Relacionado

SELECT — la cláusula de entrada con la que arranca cada query
MC SQL gotchas — lo que rompe a escala una vez que pasaste los basics

Próximas páginas de referencia: FROM · JOIN · WHERE · LIKE · CASE · INSERT INTO · String / Date / Numeric / Conversion / Aggregate / Null Functions · Style Guide.

Más snippets how-to para debugging común en producción — sends de email, largo de valores, alcance de contactos, etc.