Skip to main content

FROM — Referencia de SQL en Marketing Cloud

De dónde vienen las filas. Data Extensions vs System Data Views, aliases de tabla, y la regla de producción que te protege de las views que se desvanecen.

Referencia·Actualizado 2026-05-07·Escrito por Lira · Editado por German Medina

FROM le dice al motor de SQL desde dónde leer. En Marketing Cloud tenés exactamente dos tipos de fuente: un Data Extension que vos (o alguien de la org) creó, y una System Data View (_Subscribers, _Sent, _Open, _Click, _Bounce, _Job, etc.) que mantiene Salesforce. Si te equivocás de fuente, la query es correcta contra nada útil.

Sintaxis oficial

FROM acepta una sola tabla o vista, opcionalmente con un alias, más cláusulas JOIN encadenadas para fuentes adicionales. No hay subqueries en FROM en el subset soportado — lo que en T-SQL estándar leés como FROM (SELECT ...) sub no corre confiablemente acá. Stagéa hacia un Data Extension intermedio.

-- FROM plano, un solo Data Extension
SELECT SubscriberKey, EmailAddress
FROM master_subscribers;

-- Con alias (recomendado para legibilidad — corto, minúscula)
SELECT s.SubscriberKey, s.EmailAddress
FROM master_subscribers s;

-- Con JOIN a una segunda fuente
SELECT s.SubscriberKey, p.LastPurchase
FROM master_subscribers s
INNER JOIN purchases p
  ON s.SubscriberKey = p.SubscriberKey;

-- FROM una System Data View (mantenida por Salesforce)
SELECT SubscriberKey, EventDate
FROM _Sent
WHERE EventDate >= DATEADD(day, -7, GETDATE());

Los dos tipos de fuente y sus identificadores:

| Fuente | Cómo la referenciás | Quién la controla | |---|---|---| | Data Extension | El nombre del DE como está configurado (case-insensitive) | Vos / tu org — podés ALTER vía la UI | | System Data View | Nombre con guión bajo prefijado (_Subscribers, _Sent, _Open, _Click, _Bounce, _Unsubscribe, _Job, etc.) | Salesforce — el schema está publicado en Help, pero el comportamiento del row set no es tu contrato |

Referencia:

Lo que sobrevive en producción

Siempre aliasá las queries multi-fuente

-- EN RIESGO — cuando el JOIN tiene una tercera o cuarta fuente, calificar
-- columnas con el nombre completo de tabla se vuelve ruido; si dos DEs
-- tienen "Status", la query parsea pero lee la columna equivocada
SELECT
  master_subscribers.SubscriberKey,
  purchases.LastPurchase,
  loyalty_tier.TierName
FROM master_subscribers
INNER JOIN purchases ON master_subscribers.SubscriberKey = purchases.SubscriberKey
INNER JOIN loyalty_tier ON master_subscribers.LoyaltyTier = loyalty_tier.TierCode;

-- DURABLE — aliases cortos en minúscula, cada columna calificada, el
-- próximo dev ve de qué fuente viene cada valor de un vistazo
SELECT
  s.SubscriberKey,
  p.LastPurchase,
  lt.TierName
FROM master_subscribers s
INNER JOIN purchases p
  ON s.SubscriberKey = p.SubscriberKey
INNER JOIN loyalty_tier lt
  ON s.LoyaltyTier = lt.TierCode;

La convención que se sostiene a través de toda la sección SQL:

  • Aliases cortos de una o dos letras para las tablas primarias (s para subscribers, p para purchases, lt para loyalty_tier).
  • Calificá siempre las columnas cuando tenés más de una fuente — incluso si hoy ningún nombre choca, mañana el agregado de columnas va a crear el conflicto en silencio.
  • La primera fuente en FROM es el lado "izquierdo" de cada JOIN siguiente. Elegila intencionalmente, no por orden de tipeo.

Snapshot las System Data Views antes de leerlas en producción

_Sent, _Open, _Click, _Bounce, _Unsubscribe y compañía parecen tablas persistentes. No lo son. Después de una rotación de Send Definition, un cambio de Send Classification, o un update de plataforma de Salesforce, el row set puede cambiar o vaciarse en silencio. Una query de Journey que lee _Sent directamente y nunca entra a nadie es la forma de la falla.

La convención de nombres define si FROM se lee bien

Un FROM master_subscribers se lee limpio porque el nombre del DE comunica propiedad y contenido. Un FROM Subscribers_v2_final_USE_THIS es una nota de rehén — el próximo dev tiene que adivinar qué versión, qué dueño, qué corrida. Decidí la convención de nombres antes de crear el primer DE (ver gotchas — #7 y la próxima Style Guide).

La forma que usamos:

| Prefijo | Contiene | |---|---| | DE_ | Data Extension (master, propiedad de la implementación) | | de_stg_ | DE de staging — se reconstruye en cada corrida, seguro de truncar | | de_log_ | Log de corrida — append-only, indexado por fecha | | de_log_<sdv>_ | Snapshot de una System Data View |

FROM resuelve nombres de DE case-insensitive, pero matchear el case de tus queries con la configuración del DE hace que los diffs sean más limpios.

Lo que FROM no puede hacer

  • No hay subqueries en el subset soportado (FROM (SELECT ...) sub). Stagéa primero a un DE real, después FROM el DE stagéado.
  • No hay CTEs para sustituir FROM confiablemente entre ediciones (ver gotchas — #4).
  • No hay FROM cross-tenant. Las SQL Activities corren dentro de una sola Business Unit / MID; no podés alcanzar entre tenants desde una sola query.
  • No hay FROM contra un Data Extension de Email Studio que el usuario de la Activity no puede ver. Los permisos son por BU; si la Activity corre bajo un contexto que no tiene read sobre el DE de origen, obtenés un resultado vacío, no un error.

Decisión rápida

Leé FROM <DataExtension> cuando:

  • Vos (o tu equipo) son los dueños del DE, y su schema/contenido son lo bastante estables para depender de ellos.
  • El dato vive en MC y no necesita ser ensamblado desde sistemas externos primero.
  • El DE de origen está en la misma Business Unit que la Activity (o accesible vía un Shared Data Extension).

Leé FROM _<SystemDataView> cuando:

  • Estás haciendo snapshot una vez, hacia un DE de_log_* que vos controlás. Después las queries de producción leen del snapshot, no de la SDV.
  • Es una query de diagnóstico de una sola vez (investigación manual, no Activity scheduleada).

No uses FROM directo cuando:

  • La fuente es una System Data View Y la query está en una Automation de producción — primero hacé snapshot.
  • La fuente va a transformarse fuerte (CASE, ops de string, dedup) — stagéa el FROM crudo a un DE primero, después transformá el DE stagéado en una segunda Activity. Cada Activity se mantiene bajo el timeout de 30 minutos (ver gotchas — #3) y cada conteo de filas es auditable independientemente.

Relacionado

  • Basics — qué es una SQL Query Activity de MC y dónde corre
  • SELECT — la proyección que viene antes de FROM
  • MC SQL gotchas — ver #6 para la trampa de persistencia de System Data Views y #7 para convenciones de naming

Próximas páginas de referencia: 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.