0
私たちのアプリケーションはWebベースです。当社の取引ツールは、Java、JDK1.6、Apache Tomcat v6.0.10、PostgreSQL v8.2.3です。データベースからのチェックボックスフィールドの状態の保存と取得
アプリケーション内にページ/画面が表示されています。フィールドのはい/いいえの状態を示すだけの20〜30のチェックボックス。
自分のデザインやアーキテクチャに落ち着く直前に、自分の実装をコミュニティに返信し、他の人がこのような設計上の考慮事項をどのように見ているかについての意見やアドバイスを受けたいと思っていました。
私のソリューション/デザイン： 3つの列（EMPLOYEEID、FIELDID、STATE）を持つテーブル（USERPREFERENCE）の作成。固有のID /定数（1、2、3、...、30）で各チェックボックスフィールドを定義/指定します。したがって、この表には各ユーザーごとに20〜30のエントリがあります。これは正常なのですか、これを効果的にデータベースレベルで処理する方法がありますか？また、データベースからJavaBeanオブジェクトに自動的に20〜30フィールドの状態（行に格納された状態）をマップすることで、Javaレベルでの前後の操作が容易になります。何かアドバイス/設計案は歓迎と感謝している
EMPLOYEEID | FIELDID | STATE
100 | 1 | true
100 | 2 | true
100 | 3 | false
... | ... | ...
：
USERPREFERENCEテーブルは次のようになります。
注：0120-また、同じ機能を持つ別の4ページ/画面を開発し、各画面に20〜30個のチェックボックスフィールドを設定します。
更新日：これを考慮してください：フィールドは固定されておらず、今後新しいフィールドが追加される可能性があります。
フィールドは*固定*されていないので、今後新しいフィールドが追加される可能性があります。これを考慮して、あなたは何をアドバイスしますか？ – Gnanam
@ギャナン： どのくらいの頻度で変更されますか？毎日、毎月、毎年？ 変更の際にモデルを維持するのはどれくらい難しいですか？数分、数時間、数日？ アプリケーションのユーザーがフィールドを追加/削除できるようにする必要がある場合を除いて、このようなオーバー正規化構造は気にしません。モデルとdbの変更は、ユーザーインターフェイスとデータ検証の変更と比較すると、通常は簡単です（新しいBeanプロパティとORMマッピングを追加する）。 – Vlad
おおまかに言えば、フィールドは毎年変わるかもしれません。たとえそれが毎年起こっても、モデルとDBを維持するのに必要な時間を避ける/少なくとも減らすことを試みていますが、それは難しくないと理解しています。少なくともJavaのコーディングは可能な限り最大限に抑える必要があります。 – Gnanam