As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Controles de comparação
No SQL, a comparação literal combina uma coluna do seu conjunto de dados com um valor literal digitado diretamente na consulta. A comparação de colunas compara valores de duas colunas diferentes entre si, dentro da mesma tabela ou entre tabelas unidas.
Comportamento padrão do
Os controles de comparação são uma lista de permissões. Depois de definirallowedLiteralComparisonColumns, somente as colunas listadas poderão ser comparadas a um valor literal, e todas as colunas que você não listar serão bloqueadas. O mesmo se aplica às allowedColumnComparisonColumns comparações de coluna a coluna. Adicionar uma coluna a uma lista de permissões não a adiciona à outra.
Se você não configurarcomparisonControls, não AWS Clean Rooms aplicará nenhuma restrição de comparação — uma consulta pode comparar qualquer coluna a um valor literal ou a outra coluna.
Se você não configurarcomparisonControls, mas definir um limite mínimo de agregação, as comparações permanecerão irrestritas. No entanto, AWS Clean Rooms nunca permite uma comparação literal em uma coluna listada emidentityColumns. Essa restrição vem do próprio limite, portanto, ela se aplica independentemente de você configurar ou não os controles de comparação. Para obter mais informações, consulte Limites mínimos de agregação.
Se você configurar comparisonControls junto com colunas de saída não permitidas, os dois controles serão independentes e ambos se aplicarão. Os controles de comparação controlam quais colunas uma consulta pode comparar; as colunas de saída não permitidas controlam quais colunas podem aparecer no resultado da consulta. Uma coluna pode ser permitida em uma comparação e ainda assim ser excluída do resultado. Para obter mais informações, consulte Colunas de saída não permitidas.
Comparação literal
Uma comparação literal avalia uma coluna em relação a uma única constante codificada (uma string, número ou data). O lado direito do operador nunca muda durante a execução da consulta. Os exemplos de sintaxe incluem:
-
WHEREstatus = 'Ativo'
-
WHEREpreço > 49,99
Quando você usaLimites mínimos de agregação, AWS Clean Rooms não permite a comparação literal do identityColumns valor. Isso evita que o executor da consulta envie uma consulta filtrada para um indivíduo ou um conjunto específico de usuários. Evite permitir a comparação literal em colunas de baixa cardinalidade que podem destacar pequenos grupos ou sujeitos de dados individuais.
{ "comparisonControls": { "allowedLiteralComparisonColumns": [ "status", "price" ] } }
Escolhendo colunas para comparação literal
Permita a comparação literal somente em colunas que não identifiquem indivíduos ou pequenos grupos. Evite permitir isso em colunas de baixa cardinalidade (por exemplo, age_band, código de região grossa). Mesmo que essas colunas não sejam o identityColumns valor configurado, compará-las com literais pode restringir os resultados a uma população pequena e identificável. High-cardinality, dimensões não identificáveis, como campaign_id ou product_sku são escolhas mais seguras.
Exemplo: permitir uma comparação literal em uma coluna de campanha
Um editor configura uma regra de análise personalizada com um limite mínimo de agregação para que cada linha de saída represente pelo menos 100 usuários distintos (). user_id Um anunciante faz consultas nessa tabela, mas precisa direcionar sua análise para uma campanha publicitária específica, por exemplo, para medir o alcance de uma campanha por vez.
Como user_id é a coluna de identidade, ela não pode ser comparada a uma coluna literal, impedindo que o anunciante filtre os resultados até um único usuário. Mas como event_date são dimensões de alta cardinalidade campaign_id e não identificáveis, o editor as adicionaallowedLiteralComparisonColumns, o que permite ao anunciante filtrar por campanha e definir o escopo da análise em um intervalo de datas:
{ "aggregationThresholds": [ { "identityColumns": ["user_id"], "minimumIdentityCount": 100 } ], "comparisonControls": { "allowedLiteralComparisonColumns": ["campaign_id", "event_date"] } }
Dada a configuração anterior, essa consulta é permitida:
-- 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;
Com a mesma configuração, essa consulta é 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;
A primeira consulta ainda retorna somente linhas apoiadas por pelo menos 100 usuários distintos, enquanto as comparações literais campaign_id e event_date filtram quais linhas são consideradas. A segunda consulta é rejeitada porque tenta destacar um titular de dados individual.
Comparação de colunas
Uma comparação de colunas avalia dinamicamente o valor de uma coluna em relação ao valor de outra coluna para cada linha. Os exemplos de sintaxe incluem:
-
WHEREpreço_varejista < preço_atacadista
-
WHEREusers.id = orders.user_id
Ao usarLimites mínimos de agregação, um provedor de dados pode permitir a comparação de colunas sobre o identityColumns valor de casos de uso que exigem a junção de tabelas, como um relatório de sobreposição de público.
{ "comparisonControls": { "allowedColumnComparisonColumns": [ "user_id" ] } }
Exemplo: permitir a comparação de colunas na coluna de identidade para um relatório de sobreposição
Um editor e um anunciante querem medir a sobreposição de seu público — quantos usuários aparecem em ambos os conjuntos de dados — sem que nenhuma das partes saiba quem é um usuário individual. Isso requer a união das duas tabelasuser_id, o que é uma comparação de coluna a coluna. O editor permite que o anunciante execute uma análise de sobreposição de público com base em IDs de campanha específicos.
Por ser user_id a coluna de identidade, o editor já bloqueou comparações literais nela (então ninguém pode filtrar para uma pessoa específica). Para habilitar a união entre tabelas, o editor user_id adiciona allowedColumnComparisonColumns a. Para ativar a filtragem de campanhas, o editor adiciona campaign_id a. allowedLiteralComparisonColumns
{ "aggregationThresholds": [ { "identityColumns": ["user_id"], "minimumIdentityCount": 100 } ], "comparisonControls": { "allowedLiteralComparisonColumns": ["campaign_id"], "allowedColumnComparisonColumns": ["user_id"] } }
Dada a configuração anterior, essa consulta é permitida:
-- 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;
Com a mesma configuração, essa consulta é 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;
A junção é bem-sucedida porque uma comparação de coluna a coluna é avaliada dinamicamente por linha e não permite que o executor da consulta defina um valor conhecido. O resultado impõe o limite mínimo de agregação, garantindo que a contagem de sobreposições seja retornada somente se representar pelo menos 100 usuários distintos. A segunda consulta está bloqueada porque não email está na allowedColumnComparisonColumns lista de permissões e não pode ser usada em uma comparação — só user_id pode.
Expressões e controles de comparação
Os controles de comparação seguem comparações literais indiretas, não apenas um predicado direto. WHERE column = 'literal' Se você permitir a passagem de funções agregadas ANY_EXPRESSION internasallowedAggregateExpressionType, os controles de comparação ainda bloquearão uma comparação literal em uma coluna que não está incluída. allowedLiteralComparisonColumns Isso se aplica mesmo quando o literal está aninhado dentro de uma expressão.
O exemplo a seguir mostra uma consulta que permanece bloqueada porque não zip_code está na lista de permissões, mesmo que o literal esteja dentro de uma CASE expressão em vez de ser escrito como um predicado direto:
-- 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 isso que os dois controles são complementares: permitir expressões dentro de agregados amplia o que uma consulta pode computar, enquanto os controles de comparação ainda restringem quais colunas uma consulta pode destacar por valor. Para obter mais informações, consulte Permitindo expressões aninhadas em funções agregadas.