Sollte eine Datenbank-Tabelle über default-Werte?

Einen praktischen Fall, wo ich persönlich fand gute Verwendung von default-Werten ist für eine last_modified Spalte.

Diese Spalte nicht aktualisiert, die von gespeicherten Prozeduren oder business-Logik, wird aber automatisch aktualisiert wird ausgelöst, wenn ein Wert in der Zeile ändert. Es ist jedoch auch GETDATE() standardmäßig so, dass der Wert für eine neue Zeile enthält den Zeitstempel Wann es erstellt wurde, das ist im Grunde Wann es zuletzt geändert wurde.

ALTER TABLE users ADD CONSTRAINT dc_users_last_modified
                  DEFAULT GETDATE()
                  FOR last_modified;

Den update-trigger würde dann etwas Aussehen wie dieses:

CREATE TRIGGER trigUpdate_users 
ON users 
FOR UPDATE 
AS 
BEGIN 
    IF NOT UPDATE(last_modified) 
        UPDATE users SET last_modified = GETDATE() 
        WHERE user_id IN (SELECT user_id FROM inserted);
END 
GO

Ich würde sagen es ist eine Grauzone. Normalerweise würde ich nicht entwerfen eine neue Datenbank mit vielen Standard-Werte, aber Sie müssen oft verwenden Sie bei der Erweiterung einer bestehenden Anlage.

Beispielsweise das hinzufügen einer neuen nicht-null-Spalte zu einer vorhandenen Datenbank. Sie vielleicht nicht wollen (oder können), aktualisieren Sie den code, fügt in die Tabelle, so würden Sie brauchen, um einen Standard auf, sicherzustellen, dass jeder "legacy" - code noch einfügen von Daten (bei Standard-Wert eignet sich für den legacy-code natürlich).

tl;dr: die Default-Werte sind die business-Logik, und ich möchte, dass business-Logik in das Objekt-Modell. Als solche kann eine Datenbank nicht enthalten default-Werte.

E. g. In der Datenbank habe ich ein bit-Feld: IsANicePerson. Dieses Feld führt zu einer Eigenschaft der Person-Klasse. Optimistisch von Natur, ich will der Standardwert für diese Eigenschaft 'true' ist. So in der Person-Klasse implementiere ich diese (als Standardwert für die isANicePerson Feld sichern). Wenn würde ich den default-Werten in der Datenbank müsste ich duplizieren diese Logik. Doppelten code/Logik schlecht ist. Daher mein Einwand auf default-Werte.

Disclaimer: ich Lebe in einer OO-Welt und verwenden Linq2Sql.

Hier sind die Richtlinien, die ich persönlich benutze in Bezug auf Standard-Werte, die haben mir gut gedient in der Vergangenheit. In den folgenden Beispielen betrachten wir ein Datenbank-backend mit mehreren Anwendungen mit lese - /schreib-Zugriff auf das backend. In diesen Fällen ist es wichtig, dass die Datenbank definieren, wie die Daten modelliert werden und damit die Datenintegrität sicherzustellen.

1) CreatedDate und ModifiedDate Spalten. Diese Spalten sich in der Regel getdate () - (sql-server) als Standard festgelegt. Wie bereits in anderen Beiträgen werden diese Felder können dann aktualisiert werden, mit Trigger usw.

2) Boolean Zustand Spalten. Beispiele: "IsDefault", "IsDeleted" (für die überwachung), "IsActive",etc. Alle diese Felder haben in der Regel eine logische Standardstatus, dem sollte definiert werden, durch das Daten-Modell. Ausnahmen wäre natürlich null-Werte zulässt tri-state-boolean-Felder, in denen die null-Status darstellt, etwas über die Daten im Datensatz gespeichert.

3) Daten, die constraint-Definitionen: Spalten mit AllowNull=false und kein Standardwert definiert. In anderen Worten, einen Wert für die Anwendung erforderlich sind.

4) - Lookup-Tabelle, foreign key-Identitäten: Dies ist wahrscheinlich nicht der norm, aber für eine Menge der lookup-Tabelle Fremdschlüssel definiere ich ein Standard, der für den anfänglichen Zustand eines Datensatzes. So zum Beispiel in einer "Ereignis" - Tabelle die Fremdschlüssel-Spalte "EventTypeId"(int autoincrement) haben Standard-1 und stellen die "Allgemeine" oder so etwas. Dies deckt die meisten Szenarien, in denen, zum Beispiel, ich möchte ein Ereignis protokollieren, aber dont care über einen bestimmten Typ id.

5) Nicht-kritische string-Spalten "Beschreibung", "Comment" etc. Für diese Spalten werde ich allgemein definieren " als Standard rein zu simpify System.DbNull=>Null-conversion-handling-Anwendungen. Dies ist etwas, das kann nicht sein anwendbar in allen Szenarien vor allem, wenn die betroffene Tabelle enthält Millionen von Zeilen und Stauraum ist ein Problem.

Also zusammenfassend gesagt, verwendet die Standardwerte, um sicherzustellen, die Integrität der Daten von den tatsächlichen Daten in der Datenbank gespeichert. Das Datenmodell sollte festgelegt werden, wie diese Daten Integrität Regeln in sich und jede Anwendung die Interaktion mit es wird und sollte gezwungen werden, sich zur Beachtung dieser Regeln. Bitte beachten Sie auch, dass dies nicht die Lehre ist, und dass es immer Ausnahmen. Betrachten Sie jedes Szenario individuell, so dass es sinnvoll für Ihre Datenbank/Anwendung.