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 compara 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 que se enumeran se pueden comparar con un valor literal, y todas las columnas que no se enumeran se bloquean. Lo mismo se aplica a las allowedColumnComparisonColumns comparaciones de columna a columna. Agregar una columna a una lista de permitidos no la agrega a la otra.
Si no configuracomparisonControls, no AWS Clean Rooms aplica ninguna restricción de comparación: una consulta puede comparar cualquier columna con un valor literal o con otra columna.
Si no configura comparisonControls pero establece un umbral de agregación mínimo, las comparaciones permanecerán sin restricciones de ningún otro modo. Sin embargo, AWS Clean Rooms nunca permite una comparación literal en una columna de la lista. identityColumns Esa restricción proviene del propio umbral, por lo que se aplica independientemente de si se configuran o no los controles de comparación. Para obtener más información, consulte Umbrales mínimos de agregación.
Si los configuras comparisonControls junto con las 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 comparándola con una única constante codificada (una cadena, un número o una fecha). El lado derecho del operador nunca cambia durante la ejecución de la consulta. Entre los ejemplos de sintaxis se incluyen:
-
WHEREstatus = 'Activo'
-
WHEREprecio > 49.99
Cuando se usaUmbrales mínimos de agregación, AWS Clean Rooms no permite la comparación literal del identityColumns valor. Esto evita que el ejecutor de consultas envíe una consulta filtrada para un conjunto individual o 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" ] } }
Elegir columnas para la comparación literal
Permita la comparación literal solo en las columnas que no identifiquen a individuos o grupos pequeños. Evita permitirla en columnas de cardinalidad baja (por ejemplo, age_band, código de región grosero). Aunque estas columnas no son el identityColumns valor configurado, compararlas con los literales puede reducir los resultados a una población pequeña e identificable. High-cardinality, las dimensiones no identificativas, por ejemplo, campaign_id o product_sku son opciones más seguras.
Ejemplo: permitir la comparación literal en una columna de la campaña
Un editor 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 esta tabla, pero debe centrar su análisis en 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 una columna literal, lo que impide que el anunciante filtre los resultados hasta un solo usuario. Sin embargo, event_date dado que son dimensiones con un alto cardinalismo campaign_id y no son identificativas, el editor las añadeallowedLiteralComparisonColumns, lo que permite al anunciante filtrar por campaña y centrar el análisis en un intervalo de fechas:
{ "aggregationThresholds": [ { "identityColumns": ["user_id"], "minimumIdentityCount": 100 } ], "comparisonControls": { "allowedLiteralComparisonColumns": ["campaign_id", "event_date"] } }
Dada 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 never be compared to a literal SELECT campaign_id, COUNT(DISTINCT user_id) AS reach FROM impressions WHERE user_id = 'U-88231' GROUP BY campaign_id;
La primera consulta sigue mostrando solo filas respaldadas por al menos 100 usuarios distintos, mientras que las comparaciones literales determinan campaign_id y event_date filtran las filas que se consideran. La segunda consulta se rechaza porque intenta seleccionar 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 de forma dinámica para cada fila. Entre los ejemplos de sintaxis se incluyen:
-
WHEREprice_retail < wholesale_price
-
WHEREusers.id = orders.user_id
Cuando se usaUmbrales mínimos de agregación, un proveedor de datos puede permitir la comparación de columnas según el identityColumns valor en casos de uso que requieren unir 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 en un informe de superposición
Un editor y un anunciante quieren medir la superposición de su audiencia (el número de usuarios que aparecen en sus dos 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 de columna a columna. El editor permite al anunciante realizar un análisis de superposición de audiencias centrado en identificadores de campaña específicos.
Como user_id es la columna de identidad, el editor ya ha bloqueado las comparaciones literales en ella (por lo que nadie puede filtrar por una persona específica). Para habilitar la unión entre tablas, el editor añade user_id allowedColumnComparisonColumns A. 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 una comparación de columna a columna evalúa dinámicamente cada fila y no permite que el ejecutor de la consulta seleccione un valor conocido. El resultado impone el umbral mínimo de agregación, lo que garantiza que el recuento de superposiciones solo se devuelva si representa al menos 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é dentro. allowedLiteralComparisonColumns Esto se aplica incluso cuando el literal está anidado dentro de una expresión.
El siguiente ejemplo muestra una consulta que permanece bloqueada porque no zip_code está en la lista de valores permitidos, aunque el literal esté dentro de una CASE expresión en lugar de escribirse 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;
Por este motivo, los dos controles son complementarios: si se permiten expresiones dentro de los agregados, se amplía la capacidad de procesamiento de una consulta, mientras que los controles de comparación siguen restringiendo las columnas que una consulta puede seleccionar por valor. Para obtener más información, consulte Permitir expresiones anidadas en funciones agregadas.