Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Contrôles de comparaison

En SQL, la comparaison littérale fait correspondre une colonne de votre ensemble de données à une valeur littérale saisie directement dans la requête. La comparaison des colonnes compare les valeurs de deux colonnes différentes, soit au sein d'une même table, soit entre des tables jointes.

Comportement par défaut

Les contrôles de comparaison constituent une liste autorisée. Une fois que vous avez définiallowedLiteralComparisonColumns, seules les colonnes que vous listez peuvent être comparées à une valeur littérale, et toutes les colonnes que vous ne listez pas sont bloquées, à l'exception des comparaisons avec des valeurs toujours autorisées. Pour plus d’informations, consultez Valeurs littérales toujours autorisées. Le même comportement de liste d'autorisation s'applique allowedColumnComparisonColumns aux comparaisons entre colonnes. L'ajout d'une colonne à une liste d'autorisation ne l'ajoute pas à l'autre.

Si vous ne configurez pascomparisonControls, AWS Clean Rooms aucune restriction de comparaison n'est appliquée : une requête peut comparer n'importe quelle colonne à une valeur littérale ou à une autre colonne.

Si vous ne configurez pas comparisonControls mais que vous définissez un seuil d'agrégation minimal, les comparaisons restent par ailleurs illimitées. Cependant, AWS Clean Rooms ne permet pas une comparaison littérale sur une colonne répertoriée dansidentityColumns. La seule exception concerne les comparaisons avec des valeurs toujours autorisées. Cette restriction provient du seuil lui-même, elle s'applique donc que vous configuriez ou non les contrôles de comparaison. Pour plus d’informations, consultez Seuils d'agrégation minimaux et Valeurs littérales toujours autorisées.

Si vous configurez comparisonControls avec des colonnes de sortie interdites, les deux contrôles sont indépendants et s'appliquent tous les deux. Les contrôles de comparaison déterminent les colonnes qu'une requête peut comparer ; les colonnes de sortie non autorisées déterminent les colonnes qui peuvent apparaître dans le résultat de la requête. Une colonne peut être autorisée dans une comparaison tout en étant exclue du résultat. Pour plus d’informations, consultez Colonnes de sortie non autorisées.

Comparaison littérale

Une comparaison littérale évalue une colonne par rapport à une seule constante codée en dur (par exemple, une chaîne, un nombre, une date, une valeur booléenne ou). NULL Le côté droit de l'opérateur ne change jamais pendant l'exécution de la requête. Les exemples de syntaxe incluent :

Lorsque vous utilisezSeuils d'agrégation minimaux, n' AWS Clean Rooms autorise pas la comparaison littérale de la identityColumns valeur, sauf avec les valeurs toujours autorisées (voir). Valeurs littérales toujours autorisées Cela permet d'empêcher le lanceur de requêtes de soumettre une requête filtrée à un utilisateur individuel ou à un ensemble spécifique d'utilisateurs. Évitez d'autoriser la comparaison littérale sur des colonnes à faible cardinalité qui peuvent distinguer de petits groupes ou des sujets de données individuels.

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

Valeurs littérales toujours autorisées

AWS Clean Rooms autorise toujours une requête à comparer une colonne aux valeurs littérales suivantes, appelées valeurs toujours autorisées, même si la colonne n'est pas répertoriée allowedLiteralComparisonColumns ou est répertoriée dans : identityColumns

Ces valeurs étant fixes, un lanceur de requêtes ne peut pas les modifier pour cibler une valeur spécifique dans vos données.

Cela s'applique lorsque la colonne est comparée directement ou à l'intérieur d'une expression telle que CASEIF,COALESCE, ouUPPER. Si la colonne est encapsulée dans une autre fonction ou en arithmétique (par exemple, ABS(revenue) = 0 ourevenue - 50 = 0), la comparaison suit les commandes de comparaison.

Les comparaisons avec toute autre valeur littérale, y compris d'autres nombres tels que1, suivent les contrôles de comparaison et, pour les colonnes d'identité, la restriction du seuil d'agrégation minimum. Si vous configurez des seuils d'agrégation minimaux, ils s'appliquent toujours à chaque ligne du résultat de la requête.

Par exemple, chacune des conditions suivantes est autorisée même si la colonne n'est pas répertoriée dans allowedLiteralComparisonColumns :

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

Chacune des conditions suivantes est bloquée lorsque la colonne n'est pas répertoriée dans allowedLiteralComparisonColumns :

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

Exemple : autoriser la comparaison littérale sur une colonne de campagne

Un éditeur configure une règle d'analyse personnalisée avec un seuil d'agrégation minimal afin que chaque ligne de sortie représente au moins 100 utilisateurs distincts (user_id). Un annonceur lance des requêtes sur ce tableau mais doit étendre son analyse à une campagne publicitaire spécifique, par exemple pour mesurer la portée d'une campagne à la fois.

Comme il user_id s'agit de la colonne d'identité, elle ne peut pas être comparée à un littéral tel qu'un identifiant utilisateur spécifique. Cela permet d'empêcher l'annonceur de filtrer les résultats pour un seul utilisateur. Mais ce event_date sont des dimensions à haute cardinalité campaign_id et non identifiables, auxquelles l'éditeur les ajouteallowedLiteralComparisonColumns, ce qui permet à l'annonceur de filtrer par campagne et d'étendre l'analyse à une plage de dates :

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

Compte tenu de la configuration précédente, cette requête est autorisée :

-- 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;

Dans la même configuration, cette requête est bloquée :

-- 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 première requête ne renvoie toujours que les lignes soutenues par au moins 100 utilisateurs distincts, tandis que les comparaisons littérales permettent de event_date filtrer campaign_id les lignes prises en compte. La deuxième requête est rejetée car elle tente de distinguer une personne concernée.

Comparaison de colonnes

Une comparaison de colonnes évalue la valeur d'une colonne par rapport à la valeur d'une autre colonne de manière dynamique pour chaque ligne. Les exemples de syntaxe incluent :

Lors de l'utilisationSeuils d'agrégation minimaux, un fournisseur de données peut autoriser la comparaison de colonnes sur la identityColumns valeur pour les cas d'utilisation nécessitant la jonction de plusieurs tables, tels qu'un rapport sur le chevauchement des audiences.

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

Exemple : autorisation de la comparaison de colonnes sur la colonne d'identité pour un rapport de chevauchement

Un éditeur et un annonceur souhaitent mesurer le chevauchement de leur audience, c'est-à-dire le nombre d'utilisateurs figurant dans leurs deux ensembles de données, sans qu'aucune des parties ne sache qui est un utilisateur individuel. Cela nécessite de joindre les deux tablesuser_id, ce qui constitue une comparaison colonne par colonne. L'éditeur autorise l'annonceur à effectuer une analyse du chevauchement d'audience limitée à des identifiants de campagne spécifiques.

Parce que user_id c'est la colonne d'identité, les blocs la comparent AWS Clean Rooms déjà à une valeur spécifique, telle qu'un ID utilisateur. Cela permet d'éviter de filtrer directement vers une seule personne. Pour activer la jointure entre les tables, l'éditeur ajoute user_id àallowedColumnComparisonColumns. Pour activer le filtrage des campagnes, l'éditeur ajoute campaign_id àallowedLiteralComparisonColumns.

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

Compte tenu de la configuration précédente, cette requête est autorisée :

-- 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;

Dans la même configuration, cette requête est bloquée :

-- 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 jointure réussit car une comparaison colonne par colonne est évaluée dynamiquement par ligne et ne permet pas au lanceur de requêtes de cibler une valeur connue. Le résultat applique le seuil d'agrégation minimal, garantissant que le nombre de chevauchements n'est renvoyé que s'il représente au moins 100 utilisateurs distincts. La deuxième requête est bloquée car elle email ne figure pas dans la allowedColumnComparisonColumns liste d'autorisation et ne peut pas être utilisée dans une comparaison, elle le user_id peut uniquement.

Contrôles et expressions de comparaison

Les contrôles de comparaison suivent des comparaisons littérales indirectes, et pas seulement un WHERE column = 'literal' prédicat direct. Si vous autorisez les fonctions d'agrégation ANY_EXPRESSION internesallowedAggregateExpressionType, les contrôles de comparaison bloquent toujours une comparaison littérale sur une colonne qui n'y figure pas. allowedLiteralComparisonColumns Cela s'applique même lorsque le littéral est imbriqué dans une expression. AWS Clean Rooms permet toujours les comparaisons avec des valeurs toujours autorisées dans des expressions telles queCASE, IFCOALESCE, et. UPPER Par exemple, SUM(CASE WHEN bonus = 0 THEN salary ELSE 0 END) est autorisé. Pour plus d’informations, consultez Valeurs littérales toujours autorisées.

L'exemple suivant montre une requête qui reste bloquée car elle ne zip_code figure pas dans la liste d'autorisation, même si le littéral se trouve dans une CASE expression plutôt que sous forme de prédicat direct :

-- 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;

C'est pourquoi les deux contrôles sont complémentaires : autoriser des expressions dans des agrégats élargit le calcul d'une requête, tandis que les contrôles de comparaison limitent toujours les colonnes qu'une requête peut distinguer par valeur. Pour plus d’informations, consultez Autoriser les expressions imbriquées dans les fonctions d'agrégation.