0

コンテキスト: postgres を使用した、個人学習用の単純な webapp ゲーム。好きなようにデザインできます。

2 つのテーブル 1 つのビュー (重要ではない追加のテーブル ビュー参照があります)

Table: Research
col: research_id (foreign key to an outside table)
col: category (integer foreign key to category table)
col: percent (integer)
constraint (unique combination of the three columns)

Table: Category
col: category_id (primary key auto inc)
col: name(varchar(255))

注: この表は、ビジネス ロジックで必要な 4 つの調査カテゴリをキャプチャするために存在し、データベースの列としてハードコードするのはベスト プラクティスではないと思います

View: Research_view
col: research_id (from research table)
col: foo1 (one of the categories from category table)
col: foo2 (etc...)
col: other cols from other joins

注:上記のテーブルを適切に使用する挿入/更新/削除ステートメントがあります

私が心配している研究テーブル自体は、「スキニーテーブル」としての資格があります (Ibatis のマニュアルで見るまで、この用語を聞いたことがありませんでした)。たとえば、その中のテストデータは次のようになります。
| research_id | percent | category |
| 1 | 25 | 1 |
| 1 | 25 | 2 |
| 1 | 25 | 3 |
| 1 | 25 | 4 |
| 2 | 20 | 1 |
| 2 | 30 | 2 |
| 2 | 25 | 3 |
| 2 | 25 | 4 |

1) テーブル内のすべての列で一意のエントリをまとめて定義することは理にかなっていますか?
2) これはあなたに「におい」がありますか?

4

1 に答える 1

1

開始するためのいくつかのメモ：

制約 (3 つの列の一意の組み合わせ)

単一列の主キーを含む一意の制約を使用しても意味がありません。その列を含めると、すべての行が一意になります。

notes: this table exists to capture the 4 categories of research I want in business logic and which I assume is not best practice to hardcode as columns in the db

研究項目/エンティティが有効であるために 4 つのカテゴリすべてが定義されている必要がある場合、それらは絶対に研究テーブルの列である必要があります。これが事実であるかどうか、あなたの声明から決定的に判断することはできませんが、孤立して見た場合、あなたの仮定は誤りです. モデルが現実をできるだけ忠実に反映するようにします。

もう 1 つの要因は、追加のカテゴリを展開後にシステムに追加できることが要件であるかどうかです。カテゴリが柔軟であることと固定であることを意図しているかどうかは、デザインに絶対に影響するはずです。

1) テーブル内のすべての列で一意のエントリをまとめて定義することは理にかなっていますか?

一般的ではないと思いますが、適切な状況があることは想像できます。

2) これはあなたに「におい」がありますか?

詳細がないとなんとも言えません。

とはいえ、4 つのカテゴリすべての調査項目を表示して追加することが目的である場合は、4 つのカテゴリが意味的に調査エンティティの属性であるかどうかを検討する必要があります。

ランダムな例として、身長や体重などは人のカテゴリと見なされる可能性がありますが、別のテーブルではなく、個人テーブルにフラットに格納される可能性があります。

于 2013-11-09T21:43:49.697 に答える