Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Steuerelemente für den Vergleich In SQL gleicht der Literalvergleich eine Spalte aus Ihrem Datensatz mit einem Literalwert ab, der direkt in die Abfrage eingegeben wurde. Beim Spaltenvergleich werden Werte aus zwei verschiedenen Spalten miteinander verglichen, entweder innerhalb derselben Tabelle oder in verknüpften Tabellen. ## Standardverhalten Bei den Vergleichskontrollen handelt es sich um eine Zulassungsliste. Sobald Sie den Wert festgelegt haben`allowedLiteralComparisonColumns`, können nur die von Ihnen aufgelisteten Spalten mit einem Literalwert verglichen werden, und jede Spalte, die Sie nicht auflisten, ist gesperrt. Das Gleiche gilt `allowedColumnComparisonColumns` für Vergleiche von Spalte zu Spalte. Wenn Sie eine Spalte zu einer Zulassungsliste hinzufügen, wird sie nicht zur anderen hinzugefügt. Wenn Sie keine Konfiguration vornehmen`comparisonControls`, AWS Clean Rooms gelten keine Vergleichsbeschränkungen — eine Abfrage kann jede Spalte mit einem Literalwert oder einer anderen Spalte vergleichen. Wenn Sie nicht konfigurieren, `comparisonControls` aber einen minimalen Aggregationsschwellenwert festlegen, bleiben die Vergleiche ansonsten uneingeschränkt. Erlaubt jedoch AWS Clean Rooms niemals einen wörtlichen Vergleich für eine Spalte, die in aufgeführt ist. `identityColumns` Diese Einschränkung ergibt sich aus dem Schwellenwert selbst. Sie gilt also unabhängig davon, ob Sie Vergleichskontrollen konfigurieren oder nicht. Weitere Informationen finden Sie unter [Minimale Schwellenwerte für die Aggregation](custom-min-agg-thresholds.md). Wenn Sie die Konfiguration `comparisonControls` zusammen mit unzulässigen Ausgabespalten vornehmen, sind die beiden Steuerelemente unabhängig und gelten beide. Vergleichssteuerelemente regeln, welche Spalten eine Abfrage vergleichen kann; unzulässige Ausgabespalten bestimmen, welche Spalten im Abfrageergebnis erscheinen können. Eine Spalte kann in einem Vergleich zugelassen werden und trotzdem aus dem Ergebnis ausgeschlossen werden. Weitere Informationen finden Sie unter [Unzulässige Ausgabespalten](disallowed-output-columns.md). ## Wörtlicher Vergleich Bei einem literalen Vergleich wird eine Spalte anhand einer einzelnen hartcodierten Konstante (eine Zeichenfolge, eine Zahl oder ein Datum) ausgewertet. Die rechte Seite des Operators ändert sich während der Abfrageausführung nie. Zu den Syntaxbeispielen gehören: + WHEREstatus = 'Aktiv' + WHEREPreis > 49,99 Wenn Sie verwenden[Minimale Schwellenwerte für die Aggregation](custom-min-agg-thresholds.md), AWS Clean Rooms ist kein wörtlicher Vergleich des `identityColumns` Werts möglich. Dadurch wird verhindert, dass der Query Runner eine nach unten gefilterte Abfrage an eine einzelne oder eine bestimmte Gruppe von Benutzern sendet. Vermeiden Sie den literalen Vergleich von Spalten mit niedriger Kardinalität, durch die kleine Gruppen oder einzelne Datensubjekte herausgegriffen werden können. ``` { "comparisonControls": { "allowedLiteralComparisonColumns": [ "status", "price" ] } } ``` **Wählen Sie Spalten für den literalen Vergleich** Erlauben Sie den wörtlichen Vergleich nur für Spalten, die keine Einzelpersonen oder kleine Gruppen identifizieren. Vermeiden Sie es, dies für Spalten mit niedriger Kardinalität zuzulassen (z. B. age\_band, grober Regionscode). Auch wenn diese Spalten nicht dem konfigurierten `identityColumns` Wert entsprechen, kann der Vergleich mit Literalen die Ergebnisse auf eine kleine, identifizierbare Population einschränken. High-cardinality, nicht identifizierende Dimensionen wie `campaign_id` oder `product_sku` sind sicherere Optionen. ### Beispiel: Zulassen eines wörtlichen Vergleichs in einer Kampagnenspalte Ein Publisher konfiguriert eine benutzerdefinierte Analyseregel mit einem minimalen Aggregationsschwellenwert, sodass jede Ausgabezeile mindestens 100 verschiedene Benutzer repräsentiert (). `user_id` Ein Werbetreibender führt Abfragen anhand dieser Tabelle durch, muss seine Analyse jedoch auf eine bestimmte Werbekampagne ausdehnen, um beispielsweise die Reichweite einer Kampagne nach der anderen zu messen. Da es `user_id` sich um die Identitätsspalte handelt, kann sie nicht mit einem Literalwert verglichen werden. Dadurch wird verhindert, dass der Werbetreibende die Ergebnisse auf einen einzelnen Nutzer herunterfiltert. Da es sich jedoch `campaign_id` um Dimensionen mit hoher Kardinalität handelt, die nicht identifizierbar `event_date` sind, fügt der Publisher sie hinzu. Dadurch kann der Werbetreibende nach `allowedLiteralComparisonColumns` Kampagnen filtern und die Analyse auf einen bestimmten Zeitraum ausdehnen: ``` { "aggregationThresholds": [ { "identityColumns": ["user_id"], "minimumIdentityCount": 100 } ], "comparisonControls": { "allowedLiteralComparisonColumns": ["campaign_id", "event_date"] } } ``` Angesichts der vorherigen Konfiguration ist diese Abfrage zulässig: ``` -- 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; ``` Bei derselben Konfiguration ist diese Abfrage blockiert: ``` -- 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; ``` Die erste Abfrage gibt immer noch nur Zeilen zurück, die von mindestens 100 verschiedenen Benutzern unterstützt werden. Die literalen Vergleiche beziehen sich auf die einzelnen Zeilen `campaign_id` und `event_date` filtern, welche Zeilen berücksichtigt werden. Die zweite Abfrage wird abgelehnt, weil sie versucht, eine einzelne betroffene Person herauszusuchen. ## Vergleich der Spalten Bei einem Spaltenvergleich wird der Wert einer Spalte dynamisch für jede einzelne Zeile mit dem Wert einer anderen Spalte verglichen. Zu den Syntaxbeispielen gehören: + WHEREEinzelhandelspreis < Großhandelspreis + WHEREusers.id = orders.user\_id Bei Verwendung kann ein Datenanbieter einen Spaltenvergleich des `identityColumns` Werts für Anwendungsfälle zulassen[Minimale Schwellenwerte für die Aggregation](custom-min-agg-thresholds.md), die eine tabellenübergreifende Verknüpfung erfordern, z. B. bei einem Bericht über Zielgruppenüberschneidungen. ``` { "comparisonControls": { "allowedColumnComparisonColumns": [ "user_id" ] } } ``` ### Beispiel: Zulassen eines Spaltenvergleichs in der Identitätsspalte für einen Überlappungsbericht Ein Herausgeber und ein Werbetreibender möchten die Überschneidung ihrer Zielgruppen messen — also wie viele Nutzer in ihren beiden Datensätzen vorkommen —, ohne dass eine der Parteien erfährt, wer ein einzelner Nutzer ist. Dazu müssen die beiden Tabellen miteinander verbunden werden`user_id`, was einen Vergleich von Spalte zu Spalte darstellt. Der Publisher ermöglicht es dem Werbetreibenden, eine Analyse der Zielgruppenüberschneidung durchzuführen, die sich auf bestimmte Kampagnen-IDs bezieht. Da `user_id` es sich um die Identitätsspalte handelt, hat der Publisher bereits wörtliche Vergleiche blockiert (sodass niemand nach einer bestimmten Person filtern kann). Um die tabellenübergreifende Verknüpfung zu ermöglichen, fügt der Herausgeber Folgendes `user_id` hinzu`allowedColumnComparisonColumns`. Um die Kampagnenfilterung zu ermöglichen, fügt der Publisher `campaign_id` etwas hinzu`allowedLiteralComparisonColumns`. ``` { "aggregationThresholds": [ { "identityColumns": ["user_id"], "minimumIdentityCount": 100 } ], "comparisonControls": { "allowedLiteralComparisonColumns": ["campaign_id"], "allowedColumnComparisonColumns": ["user_id"] } } ``` Aufgrund der vorherigen Konfiguration ist diese Abfrage zulässig: ``` -- 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; ``` Bei derselben Konfiguration ist diese Abfrage blockiert: ``` -- 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; ``` Die Verknüpfung ist erfolgreich, da ein Vergleich von Spalte zu Spalte dynamisch pro Zeile ausgewertet wird und der Abfragerunner nicht auf einen bekannten Wert abzielt. Das Ergebnis setzt den minimalen Aggregationsschwellenwert durch und stellt sicher, dass die Anzahl der Überschneidungen nur zurückgegeben wird, wenn sie mindestens 100 verschiedene Benutzer repräsentiert. Die zweite Abfrage ist gesperrt, weil sie nicht auf der `allowedColumnComparisonColumns` Zulassungsliste `email` steht und nicht für einen Vergleich verwendet werden kann — sie kann nur. `user_id` ## Steuerelemente und Ausdrücke für den Vergleich Vergleichskontrollen folgen indirekten literalen Vergleichen, nicht nur einem direkten WHERE `column = 'literal'` Prädikat. Wenn Sie `ANY_EXPRESSION` interne Aggregatfunktionen zulassen`allowedAggregateExpressionType`, blockieren Vergleichskontrollen dennoch einen literalen Vergleich für eine Spalte, die sich nicht in befindet. `allowedLiteralComparisonColumns` Dies gilt auch dann, wenn das Literal in einem Ausdruck verschachtelt ist. Das folgende Beispiel zeigt eine Abfrage, die blockiert bleibt, weil sie nicht auf der Zulassungsliste `zip_code` steht, obwohl sich das Literal in einem CASE Ausdruck befindet und nicht als direktes Prädikat geschrieben ist: ``` -- 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; ``` Aus diesem Grund ergänzen sich die beiden Steuerelemente: Das Zulassen von Ausdrücken innerhalb von Aggregaten erweitert die Berechnungsmöglichkeiten einer Abfrage, während Vergleichskontrollen immer noch einschränken, welche Spalten eine Abfrage nach Wert herausgreifen kann. Weitere Informationen finden Sie unter [Verschachtelte Ausdrücke in Aggregatfunktionen zulassen](custom-min-agg-thresholds.md#custom-min-agg-nested-expressions).