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 de colonnes met en correspondance les valeurs de deux colonnes différentes, soit dans la même table, soit dans des tables jointes. ## Comportement par défaut Les contrôles de comparaison constituent une liste d'autorisations. Une fois que vous avez défini`allowedLiteralComparisonColumns`, seules les colonnes que vous répertoriez peuvent être comparées à une valeur littérale, et chaque colonne que vous ne répertoriez pas est bloquée. Il en va de même `allowedColumnComparisonColumns` pour les comparaisons colonne à colonne. L'ajout d'une colonne à une liste autorisée ne l'ajoute pas à l'autre. Si vous ne configurez pas`comparisonControls`, n' AWS Clean Rooms applique aucune restriction de comparaison : 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 minimum, les comparaisons restent par ailleurs illimitées. Cependant, AWS Clean Rooms n'autorise jamais une comparaison littérale sur une colonne répertoriée dans`identityColumns`. Cette restriction provient du seuil lui-même. Elle s'applique donc que vous configuriez ou non les contrôles de comparaison. Pour de plus amples informations, veuillez consulter [Seuils d'agrégation minimaux](custom-min-agg-thresholds.md). 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 interdites déterminent quelles colonnes 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 de plus amples informations, veuillez consulter [Colonnes de sortie interdites](disallowed-output-columns.md). ## Comparaison littérale Une comparaison littérale évalue une colonne par rapport à une seule constante codée en dur (une chaîne, un nombre ou une date). Le côté droit de l'opérateur ne change jamais pendant l'exécution de la requête. Les exemples de syntaxe incluent : + WHEREstatut = « Actif » + WHEREprix > 49,99 Lorsque vous utilisez[Seuils d'agrégation minimaux](custom-min-agg-thresholds.md), AWS Clean Rooms ne permet pas la comparaison littérale de la `identityColumns` valeur. Cela empêche le lanceur de requêtes de soumettre une requête filtrée à un individu 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" ] } } ``` **Choix de colonnes pour une comparaison littérale** Autorisez la comparaison littérale uniquement sur les colonnes qui n'identifient pas des individus ou de petits groupes. Évitez de l'autoriser sur les colonnes à faible cardinalité (par exemple, age\_band, code de région grossier). Même si ces colonnes ne constituent pas la `identityColumns` valeur configurée, leur comparaison à des littéraux peut restreindre les résultats à une petite population identifiable. High-cardinality, des dimensions non identifiables telles que `campaign_id` ou `product_sku` constituent des choix plus sûrs. ### Exemple : autoriser la comparaison littérale dans une colonne de campagne Un éditeur configure une règle d'analyse personnalisée avec un seuil d'agrégation minimum afin que chaque ligne de sortie représente au moins 100 utilisateurs distincts (`user_id`). Un annonceur effectue des requêtes dans 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, ce qui empêche l'annonceur de filtrer les résultats en fonction d'un seul utilisateur. Mais ce `event_date` sont des dimensions à cardinalité élevée `campaign_id` et non identifiables, auxquelles l'éditeur les ajoute`allowedLiteralComparisonColumns`, 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 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 première requête ne renvoie toujours que des lignes soutenues par au moins 100 utilisateurs distincts, tandis que les comparaisons littérales portent sur les lignes prises en compte `campaign_id` et `event_date` filtrent celles qui sont prises en compte. La deuxième requête est rejetée car elle tente d'identifier une personne concernée en particulier. ## Comparaison de colonnes Une comparaison de colonnes évalue dynamiquement la valeur d'une colonne par rapport à la valeur d'une autre colonne pour chaque ligne. Les exemples de syntaxe incluent : + WHEREprix\_de\_détail < prix\_de gros + WHEREusers.id = orders.user\_id Lors de l'utilisation[Seuils d'agrégation minimaux](custom-min-agg-thresholds.md), 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 tableaux, tels qu'un rapport sur le chevauchement des audiences. ``` { "comparisonControls": { "allowedColumnComparisonColumns": [ "user_id" ] } } ``` ### Exemple : Autoriser la comparaison de colonnes dans la colonne d'identité pour un rapport de chevauchement Un éditeur et un annonceur souhaitent mesurer la superposition de leur audience, c'est-à-dire le nombre d'utilisateurs apparaissant 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 tableaux`user_id`, ce qui constitue une comparaison colonne par colonne. L'éditeur autorise l'annonceur à effectuer une analyse de chevauchement d'audience portant sur des identifiants de campagne spécifiques. Comme il `user_id` s'agit de la colonne d'identité, l'éditeur a déjà bloqué les comparaisons littérales (personne ne peut donc filtrer en fonction d'une personne en particulier). 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 est réussie car une comparaison colonne à colonne évalue dynamiquement chaque ligne et ne permet pas au lanceur de requêtes de cibler une valeur connue. Le résultat applique le seuil d'agrégation minimum, 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. Seule `user_id` peut le faire. ## 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` internes`allowedAggregateExpressionType`, les contrôles de comparaison bloquent toujours une comparaison littérale sur une colonne qui n'y figure `allowedLiteralComparisonColumns` pas. Cela s'applique même lorsque le littéral est imbriqué dans une expression. L'exemple suivant montre une requête qui reste bloquée parce qu'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 d'être écrit en tant que 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 les expressions à l'intérieur d'agrégats élargit ce qu'une requête peut calculer, tandis que les contrôles de comparaison limitent toujours les colonnes qu'une requête peut sélectionner par valeur. Pour de plus amples informations, veuillez consulter [Autoriser les expressions imbriquées dans les fonctions d'agrégation](custom-min-agg-thresholds.md#custom-min-agg-nested-expressions).