私にとって、古典的な知恵は、列挙型の値（OrderStatus、UserTypesなど）をルックアップテーブルとしてデータベースに格納することです。これにより、データベースにデータの整合性を強制し、偽やヌル値などを防ぐことができます。DBの列挙型または列挙型の列挙型
しかし、これは私にとっては重複しているように感じられます。これらの値のテーブルを作成するだけでなく、扱いにくいセントラルルックアップテーブルを作成する必要がありますが、値を追加する場合は、2（またはそれ以上、生産、テスト、ライブdb ）、物事は容易に同期から外れることがあります。
まだルックアップテーブルを放置するのは難しいです。
おそらく、あるシナリオには他のシナリオよりも優位性がありますが、あなたの一般的な考えは何ですか？
私は両方を行ったことがありますが、今はコード内のクラスのように定義することをお勧めします。
新しいファイルには何も費用がかかりません。また、データベースに保存することで得られるメリットは、ビジネスルールとして処理する必要があります。
また、実際には変更されないデータベースにデータを保持することを嫌います。そしてそれはenumがこの記述に合っているようです。私は州のルックアップテーブルを持っているのは理にかなっていませんが、州の列挙クラスは私にとって意味があります。
私はそれらをデータベースに入れましたが、私は本当に守ることができませんなぜ私はそうします。それはちょうど "正しいようです"。私は、列挙型がデータベースをチェックすることによってできることの「正しい」バージョンが常に存在すると言って、それを正当化すると思います。
私はそれをDBのルックアップテーブルに残しておく必要があります。私は彼らが維持する必要はないと思うが、私はまだルックアップテーブルに行くので、私が間違っていると大したことではない。
EDIT：
私は列挙型は、DBモデルの一部ではない場合、私はコードでそれを残すことを明確にしたいです。
DBモデルの一部ではないと思われるものは何ですか？ –
テーブルへのレコードエントリの一部としてデータベースに格納されないもの。 – klabranche
スキーマの依存関係は、あなたのアーキテクチャの変更が簡単にアプリに透過的に実行することができます保証するために、データベース自体に格納する必要があります。..
それは、コード内の値の事前バインディング強制として例外ように私は、列挙型を好みます値の欠落によるものではありません
integer型の列を列挙型に関連付けることができるコード生成を使用すると、ビジネスロジックで簡単に思い出に残る列挙値。
これをドキュメントの形式と考えてください。
dBを使用するコードですでにenum定数を適切に文書化している場合は、実際に使用と保守のために重複したドキュメントセットが必要ですか？
これについてもう少し考えてみると、データベース駆動型のアプリケーションやデータベースを使ってその状態を保存するアプリケーションとして考えていると思います。私が意味するのは、他のアプリケーションやサービスで使用される独立したエンティティとしてのデータベースの考え方です。この場合、データの整合性が重要です。これとは対照的に、アプリケーションのシンプルなデータストアとしてのdbは、データの整合性ルールを適用するためのアプリケーションに依存しています。その場合、関係はおそらく必要ではない。 –
列挙型に対して無効な値を持つ行がないことを確認するにはどうすれば対処できますか？ DBにアクセスするコードを使用するだけですか？ –