0

次の状況を解決する方法を決定できません。、、、などのusers基本的な属性を持つテーブルがあり、ユーザーが選択したカテゴリを記録したい。SOに関する同様の質問と広範囲にわたるグーグルを読んだ後、私はいくつかのオプションを思いつきました。idusernameemail

a）user_categories次のフィールドを持つテーブルを作成します。

+----+---------+-------+-------+-------+
| id | user_id | sport | music | books |
+----+---------+-------+-------+-------+
|  1 |     123 |     0 |     1 |     1 |
|  2 |     543 |     1 |     0 |     0 |
|  3 |     645 |     1 |     1 |     0 |
+----+---------+-------+-------+-------+

私の場合、「カテゴリ」（スポーツ、音楽、本）はブール型です-YES / NO（1/0）は、ユーザーがこのカテゴリを選択しているかどうかを示します。また、これらの「カテゴリ」は20個以下になります（現在、私のデザインには12個あります。いずれも削除されず、新しい（よりきめ細かい）ものが追加される可能性があります）。

b）categoriesたとえば次のようなテーブルを作成します。

+----+----------+
| id | category |
+----+----------+
|  1 | sport    |
|  2 | music    |
|  3 | books    |
+----+----------+

その場合、user_categoriesテーブルは次のようになります。

+----+---------+-------------+----------------+
| id | user_id | category_id | category_value |
+----+---------+-------------+----------------+
|  1 |     123 |           1 |              0 |
|  2 |     123 |           2 |              1 |
|  3 |     123 |           3 |              1 |
+----+---------+-------------+----------------+

この2つのうちどちらを使用しますか。（または、私が完全に間違っている場合は、より良い解決策を提案できますか？）

4

3 に答える 3

1

私は個人的に、挿入とクエリの観点から、アプリケーション層の変更がゼロのカテゴリを実際に追加するのに十分な汎用性のある2番目のアプローチを好みます。最初のアプローチでは、最もコストのかかるスキーマの変更が必要であり、すべてのレイヤーに伝播する必要があります。

エンタープライズプロジェクトの1つでも同様のアプローチに従い、ビジネスオブジェクトに属性を追加しました。その場合は、属性のデータ型が同じではない少し複雑だったため、データ型ごとに1つの列を追加しました（attr_id、bit_attr_value、int_attr_value ...）。これにより、アプリ層のコードを変更せずに、管理UIを介して実行時に属性を定義するための非常に高い柔軟性が得られました。

于 2012-09-08T14:14:41.410 に答える
1

どちらの方法も可能でOKです。

一般に、「スポーツ」、「音楽」、「本」の横にカテゴリを追加する必要がないことがわかっている場合は、1つのテーブルソリューションを使用するだけで済みます。

カテゴリ（つまりフィールド）の数が増えると思われる場合は、2番目に進んでください。レコードの追加は、フィールドよりも常に簡単です。テーブルの構造を変更する必要はありません。

あなたの場合、おそらく将来いくつかのフィールドを追加することがわかっているときは、2番目の方法を選択したほうがよいでしょう。

于 2012-09-08T14:16:22.483 に答える
1

a）は、次の場合に実行可能である可能性があります。

  • 絶対にJOINを回避する必要があります（パフォーマンス上の理由から）
  • カテゴリは静的であるため、常に新しい列を追加する必要はありませんuser_categories（これは高価であり、DBMSによっては、テーブル全体の排他ロックが必要になり、変更中は事実上使用できなくなります）。

b）の元のデザインを変更し、を削除しcategory_valueます。したがって、対応する行が存在する場合はユーザーがカテゴリに含まれ、存在しuser_categoriesない場合はカテゴリに含まれません。これにより、次のことが可能になります。

  • 新しいカテゴリを簡単に追加
  • ほとんどのユーザーがすべてのカテゴリの少数派である場合、実際にスペースを節約できます（したがって、キャッシュのパフォーマンスを節約できます）。
  • ただし、より多くのJOINが必要になる場合があります（実際に何を照会する必要があるかによって異なります）。

私はb）があなたのニーズにより適していると思います。

于 2012-09-08T22:01:42.730 に答える