Sollte ich Enum ID / Werte in der Datenbank oder einer C # -Auszählung speichern?

Was ist los mit beiden? Wenn Werte benutzerdefiniert sind oder sich ändern, ist definitiv enum nicht geeignet.

Wenn Werte sich absolut nicht ändern (z. B. Geschlecht), können Sie sie als enums zur leichteren Bezugnahme in der Anwendung und auch in der Datenbank als separate Tabelle zum Erzwingen von Fremdschlüsseln und als Referenz verwenden.

Es kommt darauf an. Ich habe ein paar Vor- und Nachteile für jeden Ansatz aufgeführt. Im Allgemeinen bevorzuge ich Enums, wenn die Anwendung einen Wert verwenden muss, um Entscheidungen zu treffen. Wie Mehdrad erwähnt hat, können Sie beide Ansätze verwenden, aber es erfordert zusätzlichen Aufwand, die Listen synchron zu halten.

Nachschlagetabellen:

• Referentielle Integrität kann erzwungen werden durch Fremdschlüssel
• Einfaches Hinzufügen oder Entfernen vorhandener Werte
• Tabelle kann erweitert werden, um zusätzliche Felder hinzuzufügen (aktives Flag, etc.)
• Erfordert bei Verwendung von Geschäftsobjekten eine zusätzliche Klasse
• Einfach zu verwendender Wert und Beschreibung in Berichten

Aufzählung:

• Check constraint kann die Datenintegrität erzwingen
• Beste Wahl, wenn der Code den Wert für die Verzweigung verwenden muss (z. B. x == SalesType.Web und x == "WEB")
• Erfordert Softwareversion zum Ändern von Werten
• Die Beschreibung kann nicht in SQL-Abfragen (ohne CASE) angezeigt werden
• Enum ist möglicherweise nicht für die Anzeige in der Benutzeroberfläche geeignet (es gibt Problemumgehungen)

In meinen Projekten verwende ich meine Anwendung dbscript , um C # -Kosten von der Datenbank zu generieren, sodass Code immer mit db-Werten übereinstimmt .

Natürlich müssen Sie nur C # enums haben, wenn Ihr Code abhängig vom Wert des Type-Feldes etwas Bestimmtes tut.

Wenn die Liste stabil genug ist, um eine Aufzählung zu verwenden, würde ich eine Aufzählung in Ihrem Code und eine Tabelle in der Datenbank verwenden (machen Sie einen Fremdschlüssel für die Datenkonsistenz).