Frage

Ich habe eine Diskussion mit einem Entwickler bei der Arbeit an der Frage einer Tabelle durchgeführt, wenn eine Tabelle Standardwerte verwendet. Gibt es eine harte und schnelle Regel dafür oder ist es eine Grauzone in Best Practices?

War es hilfreich?

Lösung

Meine Regel: Wenn viele Datensätze diesen Standard verwenden (zumindest anfangs), dann benutze ich es gerne als Standard. Beispielsweise kann eine Bildtabelle für Produkte in einem Online -Shop einen Standardweg von enthält images/NoPictureYet.png. Irgendwann werden diese ersetzt, aber für Stapellasten von Daten, in denen die Bilder einfach noch nicht existieren (und vielleicht die meisten von ihnen nie!), Macht ein Standard (zumindest für mich) Sinn.

Wenn es keine vernünftige Standardeinstellung gibt (z. B. "Vorname" in einer Kundendatenbank -, möchte ich nicht Ein korrekter Wert wird eingegeben.

Aber keine harten und schnellen Regeln dafür. Es variiert ein wenig;)

Andere Tipps

Ein praktischer Fall, in dem ich persönlich eine gute Verwendung von Standardwerten gefunden habe, ist für a last_modified Säule.

Diese Spalte wird nie durch gespeicherte Prozeduren oder Geschäftslogik aktualisiert, wird jedoch automatisch durch Auslöser aktualisiert, wenn sich ein Wert in der Zeile ändert. Allerdings ist es auch auf GETDATE() standardmäßig, so dass der Wert einer neuen Zeile den Zeitstempel des Erstellens enthält, was im Grunde genommen zuletzt geändert wurde.

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

Der Update -Auslöser würde dann so aussehen wie so etwas:

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

Es kann keine harte und schnelle Regel angewendet werden. Es hängt von den Spalten ab. Es ist vielleicht völlig sinnvoll, beispielsweise einen Standardbestellentyp zu haben, aber die Idee eines Standards für eine Kunden -Telefonnummer ist nicht sinnvoll.

Ich würde sagen, es ist eine Grauzone. Normalerweise würde ich keine neue Datenbank mit vielen Standardwerten entwerfen, aber Sie müssen sie häufig verwenden, wenn Sie ein vorhandenes System verbessern.

Zum Beispiel Hinzufügen einer neuen Nicht-Null-Spalte zu einer vorhandenen Datenbank. Möglicherweise möchten Sie nicht alle Code, die in diese Tabelle eingefügt werden, aktualisieren (oder in der Lage sein). Daher müssten Sie eine Standardeinstellung darauf einstellen, um sicherzustellen für den Legacy -Code natürlich).

Standardwerte sind wichtig, wenn die Spalte einen Wert haben muss (sie ist nicht null). Wenn Sie eine Spalte von Nulls ändern, um ihnen nicht zuzulassen, ist ein Standardwert so ziemlich erforderlich, da nicht der gesamte vorhandene Code einen Wert füllen kann. Manchmal ist der Standardwert in diesem Fall so etwas wie "unbekannt". Dies gilt insbesondere dann, wenn Sie die With -Werte verwenden möchten, um die Standardwerte für das Aussehen von Datensätzen anzugeben

Standardwerte sind für Felder von entscheidender Bedeutung, mit denen die Benutzeroberfläche normalerweise nicht umgeht. Zum Beispiel haben wir Standardwerte für Date_inserted und user_insert -Spalten, von denen der Benutzer noch nie kennt. Dies ist besonders wichtig, wenn viele verschiedene Anwendungen die Daten füllen könnten, um sicherzustellen, dass niemand diese Spalten vergisst.

Dann gibt es Spalten, die normalerweise einen Wert für die Dateneingabe erhalten, die sich später ändern können. Dinge wie eine Statusspalte.

Viele Spalten können jedoch nicht wirklich einen Standard haben. Wie wäre die Standardadresse oder der Name eines Benutzers?

tl; dr: Standardwerte sind Geschäftslogik und ich möchte die Geschäftslogik im Objektmodell. Als solches kann eine Datenbank keine Standardwerte enthalten.

ZB in der Datenbank Ich habe ein Bitfeld: IsanicePerson. Dieses Feld übersetzt eine Eigenschaft in der Personklasse. Da ich von Natur aus optimistisch bin, möchte ich, dass der Standardwert für diese Eigenschaft "wahr" ist. In der Person Klasse I implementieren Sie dies (als Standardwert des IsanicePerson -Backing -Feldes). Wenn ich Standardwerte in der Datenbank zulassen würde, müsste ich diese Logik duplizieren. Duplizierter Code/Logik ist schlecht. Daher mein Einwand gegen Standardwerte.

Haftungsausschluss: Ich lebe in einer OO-Welt und verwende linq2SQL.

Es sollte ziemlich einfach sein. Wenn die Daten in der Regel für jede Zeile wie Kunden Telefonnummer eindeutig sein sollten oder der Standardwert höchstwahrscheinlich im Laufe der Zeit ändert, würde ich sie nicht verwenden. Das heißt, es ist wirklich nur nützlich für das Füllen von erstellten, modifizierten oder anderen Spalten dieser Art.

Hier sind die Richtlinien, die ich persönlich in Bezug auf Standardwerte verwende, die mir in der Vergangenheit gut gedient haben. Betrachten Sie in den folgenden Beispielen ein Datenbank -Backend mit mehreren Anwendungen mit Lese-/Schreibzugriff auf das Backend. In diesen Fällen ist es wichtig, dass die Datenbank definiert, wie die Daten modelliert werden sollen und daher die Datenintegrität sicherstellen.

1) Spalten erstellte und modifizierte Date. In diesen Spalten wird in der Regel getDate () (SQL Server) als Standard definiert. Wie in anderen Beiträgen erwähnt, können diese Felder mit Triggern usw. aktualisiert werden.

2) Boolesche Staatssäulen. Beispiele: "isDefault", "isDeleted" (zur Prüfung), "Isactive" usw. Alle diese Felder haben im Allgemeinen einen logischen Standardzustand, der vom Datenmodell definiert werden sollte. Ausnahmen davon wären offensichtlich nullable Tri-State Boolean Fields, in denen der Nullstatus etwas über die im Datensatz gespeicherten Daten darstellt.

3) Datenbeschränkungsdefinitionen: Spalten mit Alownull = Falsch und ohne Standard definiert. Mit anderen Worten, ein Wert ist von der Anwendung erforderlich.

4) Suchtabelle Fremdkey -Identitäten: Dies ist wahrscheinlich nicht die Norm, sondern für eine Vielzahl von Ausländischen Tasten für die Nachschlagtabelle werde ich einen Standard definieren, der den Anfangszustand eines Datensatzes abdeckt. In einer "Ereignis" -Tabelle hat die Spalte "EventTypeId" (int-autoincrement) in einer "Ereignis" -Tabelle also Standards 1 und repräsentiert "allgemein" oder so. Dies umfasst die meisten Szenarien, in denen ich beispielsweise ein Ereignis protokollieren möchte, aber keine bestimmte Typ -ID interessiert.

5) Nicht kritische Zeichenfolgenspalten: "Beschreibung", "Kommentar" usw. Für diese Spalten definiere ich im Allgemeinen '' 'als Standard, um das System zu simpify. Dies ist in allen Szenarien möglicherweise nicht anwendbar, insbesondere wenn die betreffende Tabelle Millionen von Reihen enthält und Speicherplatz ein Problem ist.

Verwenden Sie also die Standardeinstellungen, um die Datenintegrität der in der Datenbank gespeicherten tatsächlichen Daten sicherzustellen. Das Datenmodell sollte diese Datenintegritätsregeln in sich selbst definieren, und jede Anwendung, die mit ihm interagieren, wird und sollte gezwungen sein, diese Regeln zu respektieren. Bitte beachten Sie auch, dass dies keine Doktrin ist und dass es immer Ausnahmen geben wird. Betrachten Sie jedes Szenario individuell, damit es für Ihre Datenbank/Anwendung sinnvoll ist.

Auf jeden Fall eine Grauzone. Es ist der Klassiker, wie viel Geschäftslogik in die Datenbankfrage eingesetzt werden muss.

Wenn wir puristisch sein und sagen wollten, dass keine Geschäftslogik in die Datenbank gehört, würde die Antwort sie nie verwenden.

Wenn wir praktisch sind, können wir eine Ausnahme machen, wie wir es oft tun, und die Logik einer Standardeinstellung in die Datenbank zulassen.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top