Kunden finden, die jede Anforderung erfüllen

Kunden mit irgendeiner geforderten Fähigkeit lassen sich leicht durch einen Join finden. Kunden mit allen geforderten Fähigkeiten sind eine andere Frage. Ein Treffer beweist mindestens eine Übereinstimmung, aber keine Vollständigkeit. Diese Unterscheidung ist bei Berechtigungen, Zertifizierungen, Produktpaketen und Migrationsfreigaben wichtig.

Alle als keine fehlende Anforderung ausdrücken

Die Formulierung lautet: Ein Kunde bleibt erhalten, wenn keine Anforderung fehlt. Das äußere NOT EXISTS sucht eine nicht erfüllte Anforderung. Das innere NOT EXISTS prüft, ob diesem Kunden genau das betrachtete Merkmal fehlt. Die doppelte Verneinung entspricht damit zwei klaren fachlichen Aussagen.

CREATE TABLE #Customers(CustomerId int PRIMARY KEY);
CREATE TABLE #Required(Capability varchar(10) PRIMARY KEY);
CREATE TABLE #Has(CustomerId int,Capability varchar(10),
 PRIMARY KEY(CustomerId,Capability));
INSERT #Customers VALUES(1),(2),(3);
INSERT #Required VALUES('A'),('B');
INSERT #Has VALUES(1,'A'),(1,'B'),(1,'C'),(2,'A');
SELECT c.CustomerId FROM #Customers AS c
WHERE NOT EXISTS
(SELECT 1 FROM #Required AS r WHERE NOT EXISTS
 (SELECT 1 FROM #Has AS h WHERE h.CustomerId=c.CustomerId
  AND h.Capability=r.Capability))
ORDER BY c.CustomerId;

Kunde 1 erfüllt A und B; das zusätzliche C schließt ihn nicht aus. Kunde 2 besitzt B nicht und fällt durch. Kunde 3 hat keine Merkmale und fällt ebenfalls durch. Die Primärschlüssel legen fest, dass Mitgliedschaften und Anforderungen jeweils nur einmal vorkommen.

Die zweite Abfrage zeigt fehlende Merkmale statt nur eines Ja-Nein-Ergebnisses. Eine konkrete Lückenliste hilft einem Betriebsteam häufig mehr als ein Prozentwert mit unsichtbarem Nenner.

SELECT c.CustomerId,r.Capability AS MissingCapability
FROM #Customers AS c CROSS JOIN #Required AS r
WHERE NOT EXISTS(SELECT 1 FROM #Has AS h
 WHERE h.CustomerId=c.CustomerId AND h.Capability=r.Capability)
ORDER BY c.CustomerId,r.Capability;

Die leere Menge fachlich entscheiden

Ohne Anforderungen liefert die erste Abfrage alle Kunden. Für keinen existiert eine fehlende Anforderung. Diese logische Bedeutung kann von einem Prozess abweichen, der ohne Konfiguration keine Freigabe erlauben soll. Prüfen Sie dann die Existenz einer Anforderung separat mit EXISTS, statt den Hauptausdruck unabsichtlich zu verändern.

Alle erforderlichen Merkmale sind außerdem nicht genau die erforderlichen Merkmale. Kunde 1 wird trotz C akzeptiert. Für exakte Mitgliedschaft muss ein weiterer Ausschlusstest Kundenmerkmale außerhalb der Anforderungsliste ablehnen. Bei Freigaben kann ein zusätzliches Merkmal harmlos oder ausdrücklich verboten sein; diese Entscheidung gehört in den Vertrag.

Vermeiden Sie nullable Merkmalskennungen ohne festgelegte Bedeutung. Gleichheit verknüpft zwei NULL-Werte nicht wie zwei bekannte Kennungen. Unbekannte Codes sollten vorher abgewiesen oder abgestimmt werden, statt eine unbekannte Anforderung scheinbar zu erfüllen.

Alternativen bedeutungsgleich vergleichen

GROUP BY mit COUNT(DISTINCT Capability) kann ebenfalls funktionieren, wenn ausschließlich geforderte Merkmale gezählt und mit der richtigen Anforderungsanzahl verglichen werden. Alle Merkmale des Kunden zu zählen wäre falsch: Zwei beliebige Merkmale erfüllen nicht zwei bestimmte Anforderungen. Ohne Eindeutigkeitsschutz können doppelte Mitgliedschaften außerdem ein einfaches COUNT erhöhen.

Der Schlüssel Kunde-Merkmal unterstützt gezielte Mitgliedschaftsprüfungen. Wenn hauptsächlich kleine Merkmalsmengen die Suche bestimmen, kann ein ergänzender Index Merkmal-Kunde helfen. Messen Sie den Nutzen gegenüber zusätzlichen Schreib- und Speicherkosten. Prüfen Sie tatsächliche Pläne mit repräsentativen Mengen. Verschachteltes NOT EXISTS bedeutet nicht zwingend verschachtelte prozedurale Schleifen.

Für reproduzierbare Entscheidungen brauchen veränderliche Anforderungen und Mitgliedschaften eine konsistente Datengrenze. Speichern Sie die Anforderungsversion zusammen mit der Freigabe, wenn Prüfer später den damaligen Grund nachvollziehen müssen. Eine aktuelle Abfrage erklärt keine gestrige Entscheidung nach einer Regeländerung.

Testen Sie fehlende Anforderungen, fehlende Mitgliedschaften, exakte Übereinstimmung, Lücke, Zusatzmerkmal und durch Constraints abgewiesene Duplikate. Prüfen Sie auch, dass die Lückenliste dieselbe Regelversion verwendet wie die Freigabeentscheidung. Sonst können beide Ausgaben einzeln korrekt und zusammen widersprüchlich sein. Das Ziel ist eine erklärbare Auswahl, die irgendein, alle und genau nicht verwechselt.

Technische Referenzen: Microsoft Learn: EXISTS · Microsoft Learn: COUNT.