0

アプリケーションには次のような状況があります。

  • 私たちはUserGroupsを持っています
  • これらはユーザーが作成できます
  • ユーザーは、いくつかUserの を特定のUserGroup(n:m 関係)にマップできます。

ここUserGroupで、Java コードでアクセスできるいくつかの特別な が必要です。したがって、すべてが完了すると、ユーザーは自分で作成したUserGroupとハードコードされたグループ (もちろん削除できません) が混在して表示されるはずです。

最初のアイデアは、それらの余分なグループを作成時にデータベースに入れ、それらがそこにあるという事実に単純に依存することでしたが、それは悪い習慣だと思います. (削除したり名前を変更するとシステムがクラッシュするため)

2 番目のアイデアはenum、これらの特別なグループ用の を用意することでした。それはかなりいいでしょう。ただし、もちろん、列挙型を拡張して追加の値を配置することはできません。

ハードコードされたグループを配置できるコードの列挙型である必要があり (簡単に参照できるようにするため)、データベースに何らかの方法で接続する必要があるため、ユーザーは自分のUser <-> UserGroupマッピングを行うことができます (自分で作成したグループと私たちのために)特別なグループ)。

だから、何か他のものが必要ですが、ですか?

編集:

通常のデータベース設計を妨げない代替手段をソリューションとして選択しました。

  USER             GROUP_USER             GROUP              ACTION
--------        ----------------        ---------        --------------
id | ...        groupId | userId        id | name        groupId | enum

ご覧のとおり、いくつかの静的グループをグループ テーブル内に配置しようとはしませんが、代わりにこれらの内部アクションをユーザー インターフェイスに公開し、ユーザーは「アクション A はグループ X に属しています」と言うことができるようになりました。これにはいくつかの利点があります。ユーザーはグループの名前を選択でき、複数のグループを使用することもできます。

したがって、ACTIONテーブルは基本的にエンティティ@CollectionOfElements内にあります。GROUP

上記の問題の正確な解決策ではありませんが、私たちの場合、問題を適切に解決し、それだけが重要です;)

4

1 に答える 1

1

最初のアイデアは、それらの余分なグループを作成時にデータベースに入れ、それらがそこにあるという事実に単純に依存することでしたが、それは悪い習慣だと思います. (削除したり名前を変更するとシステムがクラッシュするため)

データベースがまったく存在しない場合や、たとえばアプリケーションで使用されるテーブルや列の名前が変更された場合にも、アプリケーションはクラッシュします。

私にとって、正しい ID または名前を持つこれらの行の存在は、正しいタイプのテーブルと列の存在と同様に、単なる前提条件です。

これらの行が存在する必要があるという事実を必ず文書化してください。アプリケーションがそれらの名前の変更や削除を許可していないことを確認し、誰かがこれらの行を削除することを本当に心配している場合は、コードで使用しているすべてのハードコードされた ID/名前に対応する行があることを確認してください起動時のデータベース。

于 2013-07-19T15:24:21.200 に答える