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 habenallowedLiteralComparisonColumns, 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 vornehmencomparisonControls, 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.

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.

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:

Wenn Sie verwendenMinimale Schwellenwerte für die Aggregation, 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"
    ]
  }
}

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:

Bei Verwendung kann ein Datenanbieter einen Spaltenvergleich des identityColumns Werts für Anwendungsfälle zulassenMinimale Schwellenwerte für die Aggregation, 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 werdenuser_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 hinzuallowedColumnComparisonColumns. Um die Kampagnenfilterung zu ermöglichen, fügt der Publisher campaign_id etwas hinzuallowedLiteralComparisonColumns.

{
  "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 zulassenallowedAggregateExpressionType, 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.