Wann sollten Sie eine Spalte Enum-Typ in Code zuordnen

Question

Vielleicht ist dies eine dumme Frage, aber wann sollten Sie eine Spalte in einen Enum-Typ zuordnen. Zum Beispiel wissen wir alle, dass die Spalte "Gender", die in der Datenbank als "M" oder "F" dargestellt wird, einer Enumeration namens Gender zugeordnet werden kann. Da es im Allgemeinen 2 Gender :) gibt, können wir ziemlich sicher sein, dass diese Enumeration nicht aktualisiert werden muss. Wie steht es aber mit enum für Geschäftslogik? Wenn Sie zum Beispiel für eine Region eine Enum verwenden, die die gesamte Region in Ihrer Datenbank darstellt, muss diese Enumeration geändert werden, wenn Sie eine andere Region in Ihre Datenbank einfügen. Daher ist eine weitere Heraufstufung erforderlich. Ist das eine gute Übung? Gibt es dafür Best Practice?

Danke!

Answer 1

Das ist eigentlich eine komplizierte Frage: Wenn Sie ein Enum verwenden, ist es traditionell, dass Sie in der DB eine Nachschlagetabelle haben, wie Reed es vorschlägt. Dies wirft jedoch das Problem auf, die Definitionen zu synchronisieren.

Wir erzeugen die Tabellen aus den enum-Definitionen als Teil unserer Build/deploy-Skripts, um sicherzustellen, dass beide die gleichen gesetzmäßigen Werte widerspiegeln.

Wir haben dann Komfortfunktionen, die ein DataSet von einer DB-Abfrage zurückgegeben und ID-Spalten zu (neu erstellten) Spalten mit Enum-Werten zuordnen. Aber wir machen das sofort, nachdem die Abfrageergebnisse abgerufen wurden. Mein Rat wäre also, sie so schnell wie möglich abzubilden, vorzugsweise in DAL.

Answer 2

Sie sind besser dran, eine separate Tabelle für die Region zu erstellen, mit ihrer eigenen, eindeutigen ID. Verwenden Sie dann die ID der Region in Ihrer Haupttabelle.

Dies ermöglicht in Zukunft mehr Flexibilität, da das Hinzufügen einer Region nur einen neuen Datensatz hinzufügt.

Alle Details zur Datenbanknormalisierung finden Sie hier.