0

データベースに以下を実装する必要がありました。

  • ユーザーが関与するアクティビティ。各アクティビティには最大 80 文字の名前を付けることができ、個別のアクティビティのみを保存する必要があります。つまり、2 人の異なるユーザーが「水泳」を好む場合、アクティビティ「水泳」は文字列として一度だけ保存する必要があります。

  • 個々のユーザーがどのような活動を行っているか。ユーザーは複数の趣味を持つことができることに注意してください。

したがって、この目的のためにテーブルを実装する必要があり、必要に応じて既存のテーブルに変更を加え、必要なキーと外部キーの関係を実装する必要があります。

これらはすべて最小限のストレージで保存する必要があります。つまり、MySQL マニュアルから適切なデータ型を選択する必要があります。新しいアクティビティが頻繁に追加され、アクティビティが削除されることはほとんどなく、個別のアクティビティの総数が 100,000 に達する可能性があると想定できます。

したがって、「user_id」を主キーとする「User」テーブルがすでにあります。


これに対する私の解決策： 「Activities」というテーブルを作成し、「activity_id」をPK（mediumint（5））として、「activity」を趣味の保存として（varchar（80））、「Link」という別のテーブルを作成して使用できますuser テーブルの「user_id」FK と「Activities」テーブルの「activity_id」FK を使用して、ユーザーが好きなアクティビティを表示します。

この質問に対する私のアプローチは正しいですか？より効率的にするためにこれを行うことができる別の方法はありますか？

1 人のユーザーが外部キー テーブル 'Link' で複数のアクティビティを実行している場合、どのように表示しますか?

4

1 に答える 1

0

あなたの考えは正しい、そして唯一の（？）方法です..それは多対多の関係と呼ばれます。

あなたが提案していることを繰り返しますが、ユーザー テーブルがあり、これにはユーザー ID があり、次にアクティビティ ID を持つアクティビティ テーブルがあります。

リレーションシップを形成するには、パフォーマンスのために主キーを必要としない 3 番目のテーブルを用意しますが、両方の列 (userid と activityid) にインデックスを付ける必要があります。

誰かがアクティビティ名を入力したときのロジックで、アクティビティ テーブルからすべてのレコードを取得し、入力された値が存在するかどうかを確認し、そうでない場合はテーブルに追加して新しいアクティビティ ID を取得し、アクティビティ ID をユーザー ID にリンクするエントリを user_activity テーブルに追加します。 .

すでに存在する場合は、そのアクティビティ ID をユーザー ID にリンクするエントリを追加するだけです。

したがって、あなたのアプローチは正しいです。最後の質問は、必要に応じて「多対多」の関係をグーグルで検索する必要があることを示しています。

于 2012-08-13T04:26:12.160 に答える