1

ユーザーのお気に入りの食品のリストを保存するdbテーブルを設計しています。次のスキーマでお気に入りのテーブルを作成しました

id, user_id, food_id

user_idとfood_idは、別のテーブルにリンクする外部キーになります。

これが効率的でスケーラブルな原因であるかどうか疑問に思っています。ユーザーが複数のお気に入りのものを持っている場合、複数行のデータが必要になります。

つまり、ユーザーが5つのお気に入りの食品を持っている場合、そのユーザーのリストを保存するために5つの行で構成されます。

これは効率的ですか？とスケーラブル？このスキーマを最適化するための最良の方法は何ですか？

事前にt​​hnx!!!

4

5 に答える 5

6

tldr; これは「結合テーブル」と呼ばれ、リレーショナル データベースで MM 関係をモデル化するための適切でスケーラブルなアプローチです。(使用される制約に応じて、「no NULL FK」スキーマで 1-M/1-1 関係をモデル化することもできます。)

ただし、idテーブルが. _ user_id, food_idPKは(user_id, food_id)この場合になります。

サロゲート (別名自動インクリメント) PKが時々議論される他のテーブルとは異なり、サロゲート PK は非常に自然な複合 PK を持っているため、通常、結合テーブルにクラッターを追加するだけです。

この場合、PK 自体は複合的ですが、「結合された」各テーブルは PK の一部によってのみ関連付けられます。実行されるクエリによっては、food_idまたはにカバリング インデックスを追加することも有益な場合があります(food_id, user_id)。

于 2012-11-28T07:20:11.977 に答える
2

サロゲート キーを削除する: サロゲート キーに特定の理由がない限りid、表から除外します。

インデックス作成の微調整:この時点で、2 つの外部キーの組み合わせである複合主キーが得られます。PK フィールドの順序は?

  • アプリケーションが主に「特定のユーザーに食べ物をください」などのクエリを実行する場合、PK は{user_id, food_id}.
  • 主なクエリが「特定の食品について、ユーザーを教えてください」である場合、PK は{food_id, user_id}.
  • 両方のクエリの「方向」が共通している場合は、PK と同じフィールドを持つが反対方向の UNIQUE INDEX を追加します。したがって、PK がオンに{user_id, food_id}なり、インデックスがオンになります{food_id, user_id}。

InnoDB テーブルはクラスター化されていることに注意してください。これにより、(この場合は「不要な」) テーブル ヒープが排除されます。それでも、上記のセカンダリ インデックスは二重ルックアップを引き起こしません (クエリを完全にカバーするため)、PK フィールドの隠れたオーバーヘッドもありません (PKと同じフィールドを逆の順序でインデックス付けするため)。

ジャンクション テーブルの設計の詳細については、この投稿をご覧ください。

于 2012-11-28T12:09:29.033 に答える
1

私の意見では、次の方法でテーブルを最適化できます。

  1. 2 つの foreighkeys を持つリレーション テーブルとして、「id」フィールドを使用する必要はありません。
  2. テーブルに「innodb」エンジンを使用する
  3. リレーション テーブルに「user_2_food」という名前を付けます。これにより、より明確になります。
  4. できるだけ小さいデータ型を使用するようにしてください。つまり、「int」よりも「smallint」の方が優れています。「UNSIGNED」属性を忘れないでください。
于 2012-11-28T10:34:06.923 に答える
0

以下の 3 つのテーブルを作成すると、効率的な設計が可能になります。

users : userId, username, userdesc
foods : foodId, foodname, fooddesc
userfoodmapping : ufid, userid, foodid, rowstate

rowstate の意味は、将来ユーザーがその食べ物を気に入らなければ、状態が -1 になることです。

于 2012-11-28T06:55:04.520 に答える
0

私の意見では、2 つのオプションがあります。

  1. ID フィールドを取り除きますが、その場合は、他の両方のキー (結合) を主キーにします。

  2. ID キーをテーブルの主キーとして保持します。

いずれにせよ、これは適切なアプローチだと思います。非効率の問題に直面したら、おそらくテーブルの一部をロードする方法やその他の手法を検討するでしょう。今のところこれで十分でしょう。

于 2012-11-28T06:56:49.907 に答える