Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Controles de comparación

En SQL, la comparación literal compara una columna del conjunto de datos con un valor literal escrito directamente en la consulta. La comparación de columnas hace coincidir los valores de dos columnas diferentes entre sí, ya sea dentro de la misma tabla o entre tablas unidas.

Comportamiento predeterminado

Los controles de comparación son una lista de permitidos. Una vez configuradasallowedLiteralComparisonColumns, solo las columnas de la lista se pueden comparar con un valor literal, y todas las columnas que no se incluyen en la lista se bloquean, excepto en el caso de las comparaciones con valores siempre permitidos. Para obtener más información, consulte Valores literales que siempre están permitidos. El mismo comportamiento de lista de permitidos se aplica a las comparaciones entre columnasallowedColumnComparisonColumns. Añadir una columna a una lista permitida no la añade a la otra.

Si no se configuracomparisonControls, no AWS Clean Rooms se aplican restricciones de comparación: una consulta puede comparar cualquier columna con un valor literal o con otra columna.

Si no configuracomparisonControls, pero sí establece un umbral de agregación mínimo, las comparaciones permanecerán libres de restricciones. Sin embargo, AWS Clean Rooms no permite realizar una comparación literal en una columna incluida enidentityColumns. La única excepción son las comparaciones con valores siempre permitidos. Esta restricción proviene del propio umbral, por lo que se aplica tanto si se configuran los controles de comparación como si no. Para obtener más información, consulte Umbrales mínimos de agregación y Valores literales que siempre están permitidos.

Si se configura comparisonControls junto con columnas de salida no permitidas, los dos controles son independientes y se aplican ambos. Los controles de comparación determinan qué columnas puede comparar una consulta; las columnas de salida no permitidas determinan qué columnas pueden aparecer en el resultado de la consulta. Se puede permitir una columna en una comparación y, aun así, excluirla del resultado. Para obtener más información, consulte Columnas de salida no permitidas.

Comparación literal

Una comparación literal evalúa una columna con respecto a una única constante codificada (por ejemplo, una cadena, un número, una fecha, un valor booleano o). NULL El lado derecho del operador nunca cambia durante la ejecución de la consulta. Los ejemplos de sintaxis incluyen:

Cuando se usaUmbrales mínimos de agregación, AWS Clean Rooms no permite la comparación literal del identityColumns valor, excepto con los valores siempre permitidos (consulte). Valores literales que siempre están permitidos Esto ayuda a evitar que el ejecutor de consultas envíe una consulta filtrada a un usuario individual o a un conjunto específico de usuarios. Evite permitir la comparación literal en columnas de baja cardinalidad, ya que pueden identificar grupos pequeños o sujetos de datos individuales.

{
  "comparisonControls": {
    "allowedLiteralComparisonColumns": [
      "status",
      "price"
    ]
  }
}

Valores literales que siempre están permitidos

AWS Clean Rooms siempre permite que una consulta compare una columna con los siguientes valores literales, denominados valores siempre permitidos, incluso si la columna no aparece allowedLiteralComparisonColumns o aparece en: identityColumns

Como estos valores son fijos, un ejecutor de consultas no puede cambiarlos para que se dirijan a un valor específico de los datos.

Esto se aplica cuando la columna se compara directamente o dentro de una expresión como CASEIF,COALESCE, oUPPER. Si la columna está incluida en otra función o en aritmética (por ejemplo, ABS(revenue) = 0 orevenue - 50 = 0), la comparación sigue los controles de comparación.

Las comparaciones con cualquier otro valor literal, incluidos otros números, siguen los controles de comparación y1, en el caso de las columnas de identidad, siguen la restricción del umbral mínimo de agregación. Si configura los umbrales de agregación mínimos, se seguirán aplicando a todas las filas del resultado de la consulta.

Por ejemplo, se permite cada una de las siguientes condiciones aunque la columna no aparezca enallowedLiteralComparisonColumns:

-- Allowed: comparisons against always-allowed values
WHERE user_id IS NOT NULL
WHERE revenue > 0
WHERE is_active = true

Cada una de las siguientes condiciones se bloquea cuando la columna no aparece enallowedLiteralComparisonColumns:

-- Blocked: other literal values, or a column wrapped in a function
WHERE revenue > 1
WHERE status_code = '0'
WHERE ABS(revenue) = 0

Ejemplo: permitir la comparación literal en una columna de campaña

Un publicador configura una regla de análisis personalizada con un umbral de agregación mínimo para que cada fila de salida represente al menos 100 usuarios distintos (user_id). Un anunciante realiza consultas en función de esta tabla, pero debe limitar su análisis a una campaña publicitaria específica, por ejemplo, para medir el alcance de una campaña a la vez.

Como user_id es la columna de identidad, no se puede comparar con un literal, como un seudónimo específico. Esto ayuda a evitar que el anunciante filtre los resultados para asignarlos a un solo usuario. Sin embargo, event_date son dimensiones de alta cardinalidad campaign_id y no son identificables, por lo que el editor las añadeallowedLiteralComparisonColumns, lo que permite al anunciante filtrar por campaña y ajustar el análisis a un intervalo de fechas:

{
  "aggregationThresholds": [
    {
      "identityColumns": ["user_id"],
      "minimumIdentityCount": 100
    }
  ],
  "comparisonControls": {
    "allowedLiteralComparisonColumns": ["campaign_id", "event_date"]
  }
}

Con la configuración anterior, se permite esta consulta:

-- Allowed: campaign_id and event_date are both in allowedLiteralComparisonColumns
SELECT campaign_id, COUNT(DISTINCT user_id) AS reach
FROM impressions
WHERE campaign_id = 'CMP-1024'
  AND event_date >= '2026-01-01'
GROUP BY campaign_id;

Con la misma configuración, esta consulta está bloqueada:

-- Blocked: user_id is the identity column and can't be compared to a specific user ID
SELECT campaign_id, COUNT(DISTINCT user_id) AS reach
FROM impressions
WHERE user_id = 'U-88231'
GROUP BY campaign_id;

La primera consulta solo muestra filas respaldadas por al menos 100 usuarios distintos, mientras que las comparaciones literales activan campaign_id y event_date filtran las filas que se tienen en cuenta. La segunda consulta se rechaza porque intenta identificar a un sujeto de datos individual.

Comparación de columnas

Una comparación de columnas evalúa el valor de una columna con el valor de otra columna de forma dinámica para cada fila. Los ejemplos de sintaxis incluyen:

Cuando se utilizaUmbrales mínimos de agregación, un proveedor de datos puede permitir la comparación de columnas en función del identityColumns valor en casos de uso que requieran la unión de varias tablas, como un informe de superposición de audiencias.

{
  "comparisonControls": {
    "allowedColumnComparisonColumns": [
      "user_id"
    ]
  }
}

Ejemplo: permitir la comparación de columnas en la columna de identidad para un informe de superposición

Un editor y un anunciante quieren medir la superposición de audiencias (el número de usuarios que aparecen en ambos conjuntos de datos) sin que ninguna de las partes sepa quién es cada usuario individual. Para ello es necesario unir las dos tablasuser_id, lo que supone una comparación columna a columna. El editor permite al anunciante realizar un análisis de superposición de audiencias basado en identificadores de campaña específicos.

Como user_id es la columna de identidad, AWS Clean Rooms ya bloquea comparándola con un valor específico, como un seudónimo. Esto ayuda a evitar que se filtre directamente a una persona. Para permitir la unión entre tablas, el publicador añade user_id aallowedColumnComparisonColumns. Para habilitar el filtrado de campañas, el editor añade campaign_id aallowedLiteralComparisonColumns.

{
  "aggregationThresholds": [
    {
      "identityColumns": ["user_id"],
      "minimumIdentityCount": 100
    }
  ],
  "comparisonControls": {
    "allowedLiteralComparisonColumns": ["campaign_id"],
    "allowedColumnComparisonColumns": ["user_id"]
  }
}

Con la configuración anterior, se permite esta consulta:

-- Allowed: user_id is compared against another column (column-to-column join)
SELECT COUNT(DISTINCT p.user_id) AS overlapping_users
FROM publisher_audience p
  JOIN advertiser_audience a
ON p.user_id = a.user_id;

Con la misma configuración, esta consulta está bloqueada:

-- Blocked: email is not in allowedColumnComparisonColumns
SELECT COUNT(DISTINCT p.user_id) AS overlapping_users
FROM publisher_audience p
  JOIN advertiser_audience a
  ON p.email = a.email;

La unión se realiza correctamente porque la comparación entre columnas se evalúa dinámicamente por fila y no permite que el ejecutor de consultas apunte a un valor conocido. El resultado impone el umbral de agregación mínimo, lo que garantiza que el recuento de superposiciones solo se devuelva si representa al menos a 100 usuarios distintos. La segunda consulta está bloqueada porque no email está en la allowedColumnComparisonColumns lista de permitidos y no se puede usar en una comparación, solo user_id se puede usar.

Controles y expresiones de comparación

Los controles de comparación siguen comparaciones literales indirectas, no solo un WHERE column = 'literal' predicado directo. Si permite el paso de funciones agregadas ANY_EXPRESSION internasallowedAggregateExpressionType, los controles de comparación seguirán bloqueando una comparación literal en una columna que no esté incluida. allowedLiteralComparisonColumns Esto se aplica incluso cuando el literal está anidado dentro de una expresión. AWS Clean Rooms aún permite realizar comparaciones con valores siempre permitidos dentro de expresiones comoCASE,IF, COALESCE y. UPPER Por ejemplo, SUM(CASE WHEN bonus = 0 THEN salary ELSE 0 END) está permitido. Para obtener más información, consulte Valores literales que siempre están permitidos.

El siguiente ejemplo muestra una consulta que permanece bloqueada porque no zip_code está en la lista de permitidos, aunque el literal esté dentro de una CASE expresión y no esté escrito como un predicado directo:

-- Blocked: zip_code is not in allowedLiteralComparisonColumns,
-- even though the literal comparison is nested inside a CASE expression
SELECT SUM(CASE WHEN zip_code = '00001' THEN salary ELSE 0 END) AS total
FROM employees;

Esta es la razón por la que los dos controles son complementarios: si se permiten expresiones dentro de los agregados, se amplía lo que una consulta puede calcular, mientras que los controles de comparación siguen restringiendo las columnas que una consulta puede distinguir por valor. Para obtener más información, consulte Permitir expresiones anidadas en funciones agregadas.