CHECK-Constraints passend zur Geschäftsregel schreiben

Eine CHECK-Constraint namens PositiveQuantity klingt nach einer Garantie für positive Mengen in jeder Zeile. Lautet der Ausdruck Quantity > 0 und erlaubt die Spalte NULL, ist dieses Versprechen unvollständig. SQL Server weist FALSE zurück; UNKNOWN durch NULL kann die Prüfung bestehen. Der Name beschreibt keine zusätzliche Ausführungsregel.

Erlaubte Zustände ausdrücklich formulieren

Die erste Tabelle zeigt die Lücke: NULL lässt sich einfügen. Ist die Menge verpflichtend, kombinieren Sie NOT NULL mit der Positivprüfung. Darf die Menge unbekannt sein, dokumentieren Sie das bewusst, statt den CHECK als Zahlenpflicht zu beschreiben.

Die zweite Tabelle modelliert Veröffentlichungen. Ein Entwurf darf keine Veröffentlichungszeit haben, eine veröffentlichte Zeile muss eine besitzen. Status ist verpflichtend und auf zwei Werte begrenzt.

CREATE TABLE #WeakRule
(
    ItemId int PRIMARY KEY,
    Quantity int NULL CHECK (Quantity > 0)
);
INSERT #WeakRule VALUES (1, NULL);
SELECT ItemId, Quantity FROM #WeakRule;

CREATE TABLE #PublicationRule
(
    ItemId int PRIMARY KEY,
    Status varchar(10) NOT NULL
        CHECK (Status IN ('Draft', 'Published')),
    PublishedAt datetime2(0) NULL,
    CHECK
    (
        (Status = 'Draft' AND PublishedAt IS NULL)
        OR
        (Status = 'Published' AND PublishedAt IS NOT NULL)
    )
);
INSERT #PublicationRule VALUES
(1, 'Draft', NULL),
(2, 'Published', '20250115T12:00:00');

BEGIN TRY
    INSERT #PublicationRule VALUES (3, 'Published', NULL);
END TRY
BEGIN CATCH
    SELECT ERROR_NUMBER() AS ConstraintError;
END CATCH;
SELECT * FROM #PublicationRule ORDER BY ItemId;
DROP TABLE #PublicationRule;
DROP TABLE #WeakRule;

Die schwache Regel liefert eine Zeile mit NULL. Die Veröffentlichungstabelle akzeptiert zwei Zeilen und lehnt die dritte ab. Die ausdrücklichen Prüfungen IS NULL und IS NOT NULL verhindern ein unbeabsichtigtes UNKNOWN in der Beziehung zwischen den Spalten.

Erstellen Sie vor einer komplexen Bedingung eine kleine Wahrheitstabelle. Prüfen Sie Draft mit und ohne Datum, Published mit und ohne Datum, unbekannten Status und NULL-Status. Daraus entstehen sinnvolle Prüfungen für Migration und Anwendung. Nur gültige Inserts zu testen lässt den wichtigsten Teil offen.

Halten Sie Ausdrücke verständlich. Lange Verneinungsketten können korrekt sein und trotzdem riskant zu erweitern. Trennen Sie unabhängige Wertebereiche von Beziehungen zwischen Spalten. Aussagekräftige Namen dauerhafter Constraints helfen, Fehler im Betrieb zuzuordnen.

Die Grenze einer Zeilenprüfung kennen

CHECK eignet sich für Regeln innerhalb der Zeile, etwa Wertebereiche oder ein Enddatum nach dem Startdatum. Es ist kein Zeitplaner, der vorhandene Zeilen beim Verstreichen der Zeit erneut überprüft. Eine Bedingung mit aktueller Uhrzeit wird bei passenden Schreiboperationen geprüft, nicht fortlaufend um Mitternacht.

Verstecken Sie auch keine zeilenübergreifenden Bestandsregeln oder Mindestanzahlen in einer skalaren Funktion innerhalb von CHECK. Andere Zeilen können sich ändern, ohne die ursprüngliche Zeile erneut zu prüfen. Löschungen bringen weitere Lücken mit sich. Verwenden Sie relationale Constraints oder eine Transaktion, die die gemeinsame Regel tatsächlich schützt.

Ein Fremdschlüssel beschreibt Zugehörigkeit zu einer anderen Tabelle direkter als eine selbstgeschriebene Suchfunktion. Eindeutigkeit gehört in eine Unique-Regel statt in eine Duplikatzählung. 'Nur eine aktuelle Zuordnung' kann einen gefilterten eindeutigen Index benötigen, nicht nur eine Datumsprüfung jeder einzelnen Zeile.

Constraints ersetzen zudem keine Autorisierung. Eine strukturell gültige Zeile kann zu einem fremden Mandanten gehören. Berechtigungsprüfung und Datenform sind getrennte Teile des Schreibvertrags.

Bestehende Daten bei der Einführung prüfen

Beim Hinzufügen einer geprüften Constraint müssen vorhandene Zeilen die Regel erfüllen. Suchen Sie Verletzungen vorab und entscheiden Sie über Korrektur oder Quarantäne. Erfundenen Standardwerten nur für einen erfolgreichen Migrationslauf fehlt möglicherweise jede fachliche Grundlage.

Eine Constraint kann aktiviert und dennoch nicht vertrauenswürdig sein, wenn alte Daten ungeprüft blieben. Kontrollieren Sie is_disabled und is_not_trusted in sys.check_constraints. WITH CHECK CHECK CONSTRAINT validiert bei einer bestehenden Constraint die vorhandenen Zeilen und stellt Vertrauen her. Planen Sie Aufwand und Sperren bei großen Tabellen.

Testen Sie auch UPDATE. Der Wechsel von Draft zu Published muss unter dieser Regel PublishedAt in derselben Anweisung setzen. Erst Status, dann Datum zu ändern erzeugt einen ungültigen Zwischenzustand. Das Scheitern zwingt die Anwendung zu einer zusammenhängenden Zustandsänderung.

Legen Sie schließlich die Übersetzung von Constraint-Fehlern in verständliche Benutzermeldungen fest. Frühe Anwendungsprüfung verbessert die Bedienung, die Datenbank bleibt die letzte Instanz. Kommt später Archived hinzu, ändern Sie Zustandsmodell, Migration und Übergangstests gemeinsam. Eine abgeschwächte Bedingung nur für fehlerfrei laufenden neuen Code ist kein tragfähiger Ersatz.

Technische Referenzen: Microsoft Learn: CHECK constraints · Microsoft Learn: sys.check_constraints.