質問

NHibernateを使用していますが、enumのような情報を格納するための一般的なパターンの1つは、enumに個別のテーブルを定義し、enumを使用するメインエンティティ/テーブルのIDを参照することです。簡単な例:

Message
-------
ID (bigint PK)
MessageTypeID (bigint FK)
Body (varchar)

MessageType
-----------
ID (bigint PK)
Value (varchar)

MessageTypeテーブルには、SMS、MMS、PSMSなどの少数の列挙値が含まれています。

enum値をこのような別のテーブルに入れる価値はありますか?列挙型の長所は、将来より簡単に拡張でき、より正規化できることですが、欠点は、メッセージを取得するたびに結合を行う必要があることです。どちらかを選択するためのブレークポイントはありますか?

役に立ちましたか?

解決

enumsを使用することは、現在行っているように別のテーブルを使用しないことを意味します。また、あなたが言ったように速く、とても簡単です。

どちらの場合でもオプションを追加できますが、質問は次のとおりです。テーブルに別のアイテムを追加する場合、アプリケーションを再コンパイルしてそのような機能を追加する必要がありますか?

つまり、アプリケーションの設計が結合され、再コンパイルが必要な新しいメッセージタイプをサポートする場合(SMS実装を含める必要があるため)、個別のテーブルを用意する価値はありません。列挙型を使用する必要があります

反対側では、エンティティにロジック(国、州テーブルなど)がない場合、またはアプリケーションが再コンパイルせずに新しいメッセージタイプをプラグインできる場合、別のテーブルを使用する必要があります。このため、テーブルを次のように変更できます。

MessageType
-----------
ID (bigint PK)
Value (varchar)
ImplementationType (varchar) (ie: Xyz.SMSSender, Xyz)

または、個別の構成ファイルを作成して、挿入された依存関係をカスタマイズできます。

他のヒント

MessageTypeテーブルに一致するIDを使用して、コード内に列挙型を作成します。その後、クラスでそれを使用するだけで、nHibernateは適切にマッピングできるはずです。

特にデータが管理データである必要がない場合、列挙テーブルから迷いました。今後、MessageTypeをさらに追加していきますか?

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top