Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Controlli di confronto
In SQL, il confronto letterale confronta una colonna del set di dati con un valore letterale digitato direttamente nella query. Il confronto tra colonne confronta i valori di due colonne diverse, all'interno della stessa tabella o tra tabelle unite.
## Comportamento predefinito
I controlli di confronto sono una lista consentita. Una volta impostati`allowedLiteralComparisonColumns`, solo le colonne elencate possono essere confrontate con un valore letterale e ogni colonna non elencata viene bloccata. Lo stesso vale `allowedColumnComparisonColumns` per i confronti da colonna a colonna. L'aggiunta di una colonna a una lista consentita non la aggiunge all'altra.
Se non AWS Clean Rooms si configura`comparisonControls`, non vengono applicate restrizioni di confronto: una query può confrontare qualsiasi colonna con un valore letterale o con un'altra colonna.
Se non si configura `comparisonControls` ma si imposta una soglia minima di aggregazione, per il resto i confronti rimangono illimitati. Tuttavia, AWS Clean Rooms non consente mai un confronto letterale su una colonna elencata in. `identityColumns` Tale restrizione deriva dalla soglia stessa, quindi si applica indipendentemente dal fatto che si configurino o meno i controlli di confronto. Per ulteriori informazioni, consulta [Soglie minime di aggregazione](custom-min-agg-thresholds.md).
Se si esegue la configurazione `comparisonControls` insieme a colonne di output non consentite, i due controlli sono indipendenti ed entrambi si applicano. I controlli di confronto determinano le colonne che una query può confrontare; le colonne di output non consentite determinano quali colonne possono apparire nel risultato dell'interrogazione. Una colonna può essere consentita in un confronto ed essere comunque esclusa dal risultato. Per ulteriori informazioni, consulta [Colonne di output non consentite](disallowed-output-columns.md).
## Confronto letterale
Un confronto letterale valuta una colonna rispetto a una singola costante codificata (una stringa, un numero o una data). Il lato destro dell'operatore non cambia mai durante l'esecuzione della query. Gli esempi di sintassi includono:
+ WHEREstatus = 'Attivo'
+ WHEREprezzo > 49,99
Quando si utilizza[Soglie minime di aggregazione](custom-min-agg-thresholds.md), AWS Clean Rooms non consente il confronto letterale sul `identityColumns` valore. Ciò impedisce al Query Runner di inviare una query filtrata a un singolo utente o a un gruppo specifico di utenti. Evita di consentire il confronto letterale su colonne a bassa cardinalità che possono individuare piccoli gruppi o singoli interessati.
```
{
"comparisonControls": {
"allowedLiteralComparisonColumns": [
"status",
"price"
]
}
}
```
**Scelta delle colonne per il confronto letterale**
Consenti il confronto letterale solo su colonne che non identificano individui o piccoli gruppi. Evita di consentirlo su colonne a bassa cardinalità (ad esempio, age\_band, codice regionale approssimativo). Anche se queste colonne non sono il `identityColumns` valore configurato, il confronto con valori letterali può restringere i risultati a una popolazione piccola e identificabile. High-cardinality, dimensioni non identificative come `campaign_id` o `product_sku` sono scelte più sicure.
### Esempio: consentire il confronto letterale su una colonna della campagna
Un editore configura una regola di analisi personalizzata con una soglia minima di aggregazione in modo che ogni riga di output rappresenti almeno 100 utenti distinti (). `user_id` Un inserzionista esegue delle query su questa tabella, ma deve limitare la propria analisi a una specifica campagna pubblicitaria, ad esempio per misurare la copertura di una campagna alla volta.
Poiché `user_id` è la colonna dell'identità, non può essere paragonata a un valore letterale, impedendo all'inserzionista di filtrare i risultati fino a un singolo utente. `event_date`Si tratta tuttavia di dimensioni ad alta cardinalità `campaign_id` e non identificative, per cui l'editore le aggiunge, il che consente all'`allowedLiteralComparisonColumns`inserzionista di filtrare per campagna e circoscrivere l'analisi a un intervallo di date:
```
{
"aggregationThresholds": [
{
"identityColumns": ["user_id"],
"minimumIdentityCount": 100
}
],
"comparisonControls": {
"allowedLiteralComparisonColumns": ["campaign_id", "event_date"]
}
}
```
Data la configurazione precedente, questa interrogazione è consentita:
```
-- 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;
```
Data la stessa configurazione, questa interrogazione è bloccata:
```
-- 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 prima query restituisce ancora solo le righe supportate da almeno 100 utenti distinti, mentre la ricerca letterale confronta `campaign_id` e `event_date` filtra le righe considerate. La seconda query viene rifiutata perché tenta di individuare un singolo interessato.
## Confronto tra colonne
Un confronto tra colonne valuta il valore di una colonna rispetto al valore di un'altra colonna in modo dinamico per ogni singola riga. Gli esempi di sintassi includono:
+ WHEREprezzo\_vendita al dettaglio < prezzo\_all'ingrosso
+ WHEREusers.id = orders.user\_id
Durante l'utilizzo[Soglie minime di aggregazione](custom-min-agg-thresholds.md), un fornitore di dati può consentire il confronto tra colonne sul `identityColumns` valore per i casi d'uso che richiedono l'unione tra tabelle, ad esempio un rapporto sulla sovrapposizione dell'audience.
```
{
"comparisonControls": {
"allowedColumnComparisonColumns": [
"user_id"
]
}
}
```
### Esempio: consentire il confronto tra colonne nella colonna di identità per un report di sovrapposizione
Un editore e un inserzionista vogliono misurare la sovrapposizione del pubblico, ossia quanti utenti compaiono in entrambi i set di dati, senza che nessuna delle parti sappia chi sia il singolo utente. Ciò richiede l'unione delle due tabelle`user_id`, ovvero un confronto da colonna a colonna. Il publisher consente all'inserzionista di eseguire un'analisi della sovrapposizione del pubblico basata su ID di campagna specifici.
Poiché `user_id` si tratta della colonna relativa all'identità, l'editore ha già bloccato i confronti letterali su di essa (quindi nessuno può filtrare in base a una persona specifica). Per abilitare l'unione tra tabelle, l'editore aggiunge `user_id` a. `allowedColumnComparisonColumns` Per abilitare il filtro delle campagne, l'editore aggiunge `campaign_id` a`allowedLiteralComparisonColumns`.
```
{
"aggregationThresholds": [
{
"identityColumns": ["user_id"],
"minimumIdentityCount": 100
}
],
"comparisonControls": {
"allowedLiteralComparisonColumns": ["campaign_id"],
"allowedColumnComparisonColumns": ["user_id"]
}
}
```
Data la configurazione precedente, questa interrogazione è consentita:
```
-- 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;
```
Data la stessa configurazione, questa interrogazione è bloccata:
```
-- 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;
```
L'unione ha esito positivo perché un confronto da colonna a colonna valuta dinamicamente per riga e non consente al gestore della query di scegliere come target un valore noto. Il risultato impone la soglia minima di aggregazione, garantendo che il conteggio delle sovrapposizioni venga restituito solo se rappresenta almeno 100 utenti distinti. La seconda query è bloccata perché non `email` è presente nella `allowedColumnComparisonColumns` lista consentita e non può essere utilizzata in un confronto, ma solo. `user_id`
## Controlli ed espressioni di confronto
I controlli di confronto seguono confronti letterali indiretti, non solo un predicato diretto WHERE`column = 'literal'`. Se si autorizzano le funzioni aggregate `ANY_EXPRESSION` interne`allowedAggregateExpressionType`, i controlli di confronto bloccano comunque un confronto letterale su una colonna che non è presente. `allowedLiteralComparisonColumns` Ciò vale anche quando il valore letterale è annidato all'interno di un'espressione.
L'esempio seguente mostra una query che rimane bloccata perché non `zip_code` è nella lista consentita, anche se il valore letterale è all'interno di un'CASEespressione anziché scritto come predicato diretto:
```
-- 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;
```
Ecco perché i due controlli sono complementari: consentire espressioni all'interno di aggregati amplia ciò che una query può calcolare, mentre i controlli di confronto limitano ancora le colonne che una query può individuare in base al valore. Per ulteriori informazioni, consulta [Consentire espressioni annidate nelle funzioni aggregate](custom-min-agg-thresholds.md#custom-min-agg-nested-expressions).