Skip to main content

Data Cloud SQL: el dialecto con el que consultás el perfil unificado

Qué es Data Cloud SQL: un dialecto ANSI-compliant que corrés en el Query Editor y la Query API sobre DMOs, DLOs y Calculated Insight Objects — el perfil unificado, no Data Extensions planos. Las reglas de nombres, el comportamiento de las cláusulas, y qué se traslada desde Marketing Cloud SQL.

Referencia·Actualizado 2026-06-01·Escrito por Lira · Editado por German Medina

Data Cloud SQL es el dialecto ANSI-compliant que usás para hacerle una pregunta al modelo de datos unificado — en el Query Editor para trabajo ad-hoc, o a través de la Query API para cualquier cosa programática. Si hoy escribís SQL contra los Data Extensions de Marketing Cloud, la superficie te resulta familiar. Los objetos de abajo no lo son: consultás Data Model Objects, Data Lake Objects y Calculated Insight Objects sobre un perfil resuelto, no una tabla plana que cargaste.

Esta página es la referencia del dialecto — qué es Data Cloud SQL. El crosswalk completo, hábito por hábito, desde Marketing Cloud SQL vive en su propia página (ver bridging desde Marketing Cloud SQL); acá cubrimos qué consultás, cómo nombrarlo, y cómo se comportan las cláusulas.

Qué consultás: tablas sobre el perfil unificado

En Data 360 (antes Data Cloud), "tabla" significa uno de tres tipos de objeto, y los tres son consultables a través de la misma superficie SQL:

  • Data Model Objects (DMOs) — la capa armonizada. Los API names terminan en __dlm. Los DMOs estándar cargan el namespace ssot__ (ssot__Individual__dlm, ssot__ContactPointEmail__dlm); las variantes resueltas, post-identity-resolution, dejan caer el prefijo (UnifiedIndividual__dlm). Esto es lo que deberías consultar casi siempre.
  • Data Lake Objects (DLOs) — el aterrizaje crudo de un stream, en la forma del sistema de origen. Los API names terminan en __dll. Consultables, pero consultar un DLO directo hereda el desorden del origen (ver gotchas de Query & Insights — gotcha 1).
  • Calculated Insight Objects (CIOs) — las dimensiones y measures que un Calculated Insight pre-computó, expuestas como tabla consultable.

La distinción que más importa para cualquiera que llega desde Marketing Cloud: esto no son Data Extensions. Un DMO es una vista sobre el perfil unificado que construyó la identity resolution. Consultá UnifiedIndividual__dlm y estás contando personas, no filas que importaste — una diferencia que rompe silenciosamente la reconciliación si asumís lo contrario.

Nombres: calificalos y ponéles namespace

Los nombres de tabla y columna de Data 360 son los API names del objeto y del campo, y casi siempre contienen mayúsculas. Eso moldea cómo los referenciás.

  • Entrecomillá solo cuando tenés que — pero es un hábito seguro. Entrecomillar con comillas dobles un identificador es necesario solo cuando su case se plegaría, o cuando el nombre choca con una palabra reservada. Como los API names de Data 360 mezclan mayúsculas y minúsculas (ssot__Individual__dlm), entrecomillar por reflejo es un hábito defendible. Los ejemplos de esta subcategoría quedan sin comillas por legibilidad, porque estos nombres son inequívocos; agarrá las comillas en el momento en que un nombre esté en riesgo.
  • Los campos custom terminan en __c. Los campos estándar cargan también el namespace ssot__ (ssot__Id__c). Los campos que agregás vos aterrizan como __c.
  • Calificá con un alias cuando hacés join. Una vez que hay más de un objeto en juego, prefijá cada columna con el alias de su tabla para que el motor — y el próximo que lea — sepa de qué objeto vino.
-- Consultá el perfil resuelto directo. Campos con namespace ssot__; aliaseá y calificá.
-- Contando individuos unificados, NO filas importadas crudas.
SELECT
  i.ssot__Id__c          AS individual_id,
  i.ssot__FirstName__c   AS first_name
FROM UnifiedIndividual__dlm i
WHERE i.ssot__FirstName__c IS NOT NULL
LIMIT 100;

El Query Editor

El Query Editor es la superficie de UI dentro de Data 360 donde corrés Data Cloud SQL ad-hoc y ves resultados al instante — el equivalente al reflejo de Query Studio que un practicante de Marketing Cloud ya tiene, pero apuntado al modelo unificado. Es donde explorás un objeto, validás un camino de JOIN antes de cablearlo a algo, y verificás un count contra lo que esperabas.

Es para trabajo interactivo. Cualquier cosa que necesite correr en un schedule, volver a una aplicación, o paginar un result set grande va en la Query API en su lugar — y la Query API tiene su propio comportamiento de paginación y async que los resultados de una sola pantalla del Editor esconden.

Cómo se comportan las cláusulas

Como el dialecto es ANSI-compliant, la forma de una sentencia es la que esperarías — y eso es justo lo que hace que valga la pena enunciar las pocas diferencias sin vueltas.

  • SELECT / FROM — estándar. El target del FROM es un DMO, DLO o CIO. El aliasing funciona como siempre.
  • WHERE — predicados ANSI, AND/OR/IN/IS NULL. El filtro corre sobre el perfil resuelto, así que un WHERE sobre UnifiedIndividual__dlm filtra personas, no filas de origen.
  • JOIN — INNER, LEFT/FULL OUTER están disponibles, pero un join solo funciona donde la relación existe en el modelo. Una traversal que nadie modeló no es un error de runtime que debugueás; el camino simplemente no está. Unir un objeto de origen al individuo unificado no es un join directo — traversás a través del objeto puente IndividualIdentityLink__dlm que mantiene la resolución de identidad (los nombres exactos del link y del campo de origen siguen el modelo de tu org). Para keys nullable, Data Cloud SQL soporta IS NOT DISTINCT FROM para que dos NULL matcheen en vez de descartar la fila — una diferencia real frente a un join ingenuo con =.
  • GROUP BY / agregados — COUNT, SUM, COUNT(DISTINCT …), MIN/MAX y HAVING se comportan como en ANSI SQL. El grain por el que agrupás es el grain de la respuesta; agrupá por la key equivocada y el número está mal en todos lados donde se lee.
  • ORDER BY / LIMIT — soportados. En la Query API, LIMIT no te salva de la paginación — un result set grande igual pagina.
-- Agregá al grain del comprador. La key del GROUP BY ES el grain de la respuesta.
SELECT
  o.ssot__BuyerId__c                AS buyer,
  COUNT(DISTINCT o.ssot__Id__c)     AS order_count,
  SUM(o.ssot__GrandTotalAmount__c)  AS lifetime_value
FROM ssot__SalesOrder__dlm o
GROUP BY o.ssot__BuyerId__c
HAVING COUNT(DISTINCT o.ssot__Id__c) > 1
ORDER BY lifetime_value DESC;

Qué se traslada desde Marketing Cloud SQL, y qué es distinto

Para un practicante de Marketing Cloud, el parecido es la trampa: es SQL, así que se siente resuelto, justo hasta que no lo está.

Se traslada:

  • La forma ANSI base — SELECT … FROM … WHERE … GROUP BY … ORDER BY — es el mismo esqueleto que ya escribís.
  • Los agregados estándar (COUNT, SUM, COUNT(DISTINCT …)) y la lógica de predicados se comportan como esperás.
  • La disciplina de elegir una key estable y contar el objeto correcto se traslada directo — es el mismo instinto que aplicás a SubscriberKey, ahora aplicado al perfil unificado.

Es distinto:

  • No hay System Data Views. No existe _Subscribers, _Sent, _Open ni _Click. El engagement vive en DMOs que modelás e ingerís, no en vistas que la plataforma te entrega.
  • No hay Data Extensions planos. Consultás DMOs sobre un perfil resuelto. FROM UnifiedIndividual__dlm cuenta personas; el viejo hábito de contar filas en un DE no mapea limpio.
  • Los identificadores van con namespace. ssot__Individual__dlm lleva el prefijo ssot__ y el sufijo __dlm, no un nombre de DE pelado — entre comillas dobles solo cuando un nombre con mayúsculas está en riesgo.
  • Los joins tienen que estar modelados. En MC unís dos DEs cualesquiera por cualquier campo que matchee. En Data 360 la relación tiene que existir primero en el modelo.
  • Dos dialectos SQL, no uno. El dialecto de esta página — el que hablan el Query Editor y la Query API — no es el dialecto con el que escribís para crear un Calculated Insight. Las definiciones de CI usan otra superficie SQL con sus propias reglas. Leer el resultado de un CI de vuelta es SQL normal; autorear el CI es un dialecto aparte. No asumas que una función que anda en uno anda en el otro.

La página del crosswalk recorre cada hábito trasladable y cada misfire en detalle. Esta página es el límite: Data Cloud SQL es ANSI sobre el modelo unificado, con namespace, con joins modelados y un dialecto hermano para los Calculated Insights.

Relacionado

Referencia: