Ist es eine gute Methode, CHECK-Einschränkungen zu verwenden, um Daten während einer INSERT-Anweisung zu validieren?

Question

Welcher Weg wird als besser angesehen, um die Eingabe von Daten zu validieren, bevor Sie sie in eine Tabelle einfügen, CHECK-Einschränkungen verwenden oder if-Anweisung verwenden? Gibt es bessere Möglichkeiten, es zu validieren?

1)

DECLARE 
INVALID_DATE EXCEPTION; 
... 
-- Check if date is valid 
IF TO_DATE(dt,'DD/MM/YYYY') > TO_DATE('10/10/2010','DD/MM/YYYY')THEN 
RAISE INVALID_DATE; 
END IF; 

-- Insert data only if it is valid 
INSERT INTO Table VALUES(dt); 

EXCEPTION 
WHEN INVALID_DATE 
     THEN DBMS_OUTPUT.PUT_LINE('Date is not valid'); 
... 

2)

... 
-- Do NOT check if date is valid and let an 
-- CHECK constraint exception(CH_TABLE1) be raised if it is invalid 
INSERT INTO Table VALUES(dt); 

EXCEPTION 
WHEN CHECK_CONSTRAINT_VIOLATED THEN 
    IF SQLERRM LIKE 'ORA-02290:%CH_TABLE1%' THEN 
     DBMS_OUTPUT.PUT_LINE('Date is not valid'); 
    ... 
    END IF; 
... 

Answer 1

Es kommt darauf an - oft ist ein mehrschichtiger Ansatz erforderlich.

Zum Beispiel können Sie eine Reihe von einfachen Geschäftsregeln haben, die direkt in der Datenbank als Prüfbedingungen gepflegt werden können. Ich benutze diese nur für einfache, in sich geschlossene Kontrollen.

Beispiel - ein Y/N-Flag überprüft:

alter table example_table add constraint ck_example_table_flag 
check (flag is null or flag in ('Y', 'N'); 

In diesem Fall, wenn Sie einen anderen Wert in dieser Spalte erhalten Sie wissen, dass die Daten sind schlecht, und dies ist keine Regel Das wird sich im Laufe der Zeit ändern. Durch Hinzufügen dieser Einschränkung wird verhindert, dass eine Anwendung Ihre Daten beschädigt.

Für kompliziertere Geschäftsregeln, die möglicherweise nicht in sich abgeschlossen sind, zum Beispiel wenn ein Datum von der Person, die den Wert eingibt, oder vom Inhalt eines anderen Feldes in einer anderen Tabelle abhängt, würde ich das in der 'Anwendung' behandeln .

Manchmal ist die 'Anwendung' die Datenbank - in diesem Fall können Ihre Prüfbedingungen in Tabellenauslösern oder in einem gepackten pl/sql vorliegen, das alle Tabellenaktualisierungen verarbeitet. Zum Beispiel:

example_app.update_data(id => 1000, value => 'foo'); 

Ist dies, wie Sie Ihr Daten-Updates behandelt werden, es ist nichts falsch mit Ihrem Geschäftsregeln als Check-Einschränkungen Umgang, Trigger mit Schecks oder direkt im update_data Verfahren.

In vielen Enterprise-Umgebungen werden die Anwendungsschicht und die Datenbankschicht von verschiedenen Teams gehandhabt. Wenn Sie in dem Team sind, das die Anwendungsebene unterstützt, ist es möglicherweise zu mühsam, eine Änderungsanforderung für das Datenbankteam zu stellen, um eine Prüfbedingung zu setzen. In diesem Fall wird das Hinzufügen von ein wenig Logik zur Anwendungsebene mehr bewirken einfach. Umgekehrt mag das Datenbankteam es einfacher finden.

@Bohemian makes an excellent point über die Verwendung von Prüfbedingungen, um die Datenintegrität zu erzwingen, wenn mehrere Clients vorhanden sind.

Answer 2

Wenn Updates/Inserts aus mehreren Anwendungen/scripts kommen kann, insbesondere Ad-hoc-Abfragen, dann setzt ein Check-Constraint die erforderliche Geschäftslogik in einem Platz, was eine gute Sache ist.

Wenn Updates/Einfügungen von einer Anwendung/Quelle kommen, ist es wahrscheinlich besser, die Überprüfung in der Anwendung (in diesem Fall eine gespeicherte Prozedur) durchzuführen.

Eine Check-Constraint ist ein Catch alle, aber es ist etwas versteckt.

Answer 3

Eine weitere Überlegung zugunsten der Verwendung von Check-Constraints ist, dass sie die Performance verbessern können, indem der Optimierer den Schluss ziehen kann, dass einige Werte in der Tabelle nicht vorhanden sein können.

eine Einschränkung in der Gegenwart, die eine Datumsspalte begrenzt, das überprüfen:

my_col> Datum ‚2010-01-01‘

... eine Abfrage mit einem Prädikat wie:

my_col = Datum '2009-01-01'

... kann feststellen, dass keine Zeilen von dieser Tabelle zurückgegeben werden.