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 configuradas`allowedLiteralComparisonColumns`, 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 configura`comparisonControls`, 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](custom-min-agg-thresholds.md). 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](disallowed-output-columns.md). ## 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 usa[Umbrales mínimos de agregación](custom-min-agg-thresholds.md), 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ñade`allowedLiteralComparisonColumns`, 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 usa[Umbrales mínimos de agregación](custom-min-agg-thresholds.md), 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 tablas`user_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` a`allowedLiteralComparisonColumns`. ``` { "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` internas`allowedAggregateExpressionType`, 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](custom-min-agg-thresholds.md#custom-min-agg-nested-expressions).