ist das Hinzufügen von reservierten Felder für zukünftige Werte eine gute Idee

Question

Ich habe Tabellen wie Customer, Purchase usw., die manchmal mit ihnen verbunden sind Dokumente, durch Dokumente meine ich einige Datei irgendwo (wie ein gescanntes Führerschein oder etwas)

Wir kann nicht die Anwendung diese Dokumente direkt in der Datenbank habe ich für diese eine unique~~POS=TRUNC Spalte so stattdessen laden haben

Meine Frage (Sollte ich stattdessen einen Dateihash haben?):
In Zukunft könnten wir mehrere Dokumente mit einem in Verbindung gebracht Tabelle, so dachte ich über das Hinzufügen von zusätzlichen Feldern wie:

Kunden
+ DriversLicenseDoc
+ Document1 // für die Zukunft
+ Document2 // zukünftige Verwendung

So in der Zukunft, wenn sie sich entscheiden, sie ein anderes Dokument möchte ich nur haben Aktualisieren Sie mein Entity-Framework-Modell und benennen Sie die Spalte in meinem Modell um und die Datenbank muss sich nicht ändern?

Ist das so allgemein gemacht? Irgendwelche besseren Ideen? Die Kehrseite, die ich sehe, ist, dass ich all diese zukünftigen Werte für null halten muss? Vielleicht ist das kein Nachteil?
Möchten Sie auch wissen, wie Sie mit Änderungen im Datenbankschema nach der Bereitstellung im Allgemeinen zurechtkommen?

Answer 1

Nein, es ist eigentlich eine wirklich schlechte Idee. Entweder Sie sehen die Verwendung richtig voraus, in diesem Fall fügen Sie sie hinzu, wie sie sein sollen, oder Sie erraten nur, was passieren könnte, in welchem ​​Fall Sie warten sollten, bis Sie es wissen.

Die Vorgehensweise bei Schemaänderungen nach der Bereitstellung besteht darin, das Schema (und den zugehörigen Code) nach der Bereitstellung zu ändern. Sie sollten in das Akronym "YAGNI" schauen. In meiner Meinung, sollte jeder Aufwand, der nicht sofort benötigt wird, als Aufwand für etwas, das möglicherweise nie benötigt werden, angesehen werden. Mit anderen Worten, verschwendete Anstrengung.

Wenn eine unbekannte Anzahl von Dokumenten vorhanden ist, handelt es sich um eine einfache Eins-zu-Viele-Beziehung von der Kundentabelle zur Dokumententabelle, wobei jedes Dokument in der Tabelle den Dokumenttyp und die Dokumentnutzlast enthält :

customers: 
    custid primary key 
    <all other customer data> 
documents: 
    docid primary key 
    custid references customers(custid) 
    <all other document data> 

Auf diese Weise kann jeder Kunde so viele Dokumente haben, wie Sie wünschen, von so vielen Typen, wie Sie benötigen.