0

Web サイトのプロファイル ページには、すべてのユーザー向けにこれらの種類のフィールドが含まれています。

  1. 1 対 1 のフィールド - 名前、年齢、性別
  2. 一対多のフィールド - 職歴、学歴
  3. 多対多フィールド - 言語、賞、委員会

ツール - MYSQL および PHP [ただし、変更は可能です]

1 つのユーザー テーブルを作成することにしました。

tbl_user -> PK - user_id , FK - profile_id

ユーザーに対して一度だけ発生するすべてのフィールドを、テーブル tbl_user_profile に属性として追加します。

tbl_user_profile -> PK - profile_id

次に、1対多の種類の関係を満たすために、テーブルの束を作成します .これは、時間の経過とともに簡単に大きくなります..

tbl_user_jobs , tbl_user_education
FK - user_id [ INNO DB ]

そして、MANY_TO_MANY モデリング用の参照テーブルとして一連のテーブルを作成します -

tbl_ref_awards, tbl_ref_languages, tbl_ref_committee
PK = REF_ID

tbl_user_languages, tbl_user_awards, tbl_user_committee
FK - user_id , REF_ID

ここで、先ほど説明した詳細を含むプロファイル ページをレンダリングする必要があります。ページが読み込まれるたびに、テーブルtbl_user_*テーブルを tbl_user と結合し、ページに入力する必要があります。

まずこのデザインでいいのかな？第 2 に、多くのテーブルが page で [7 回] 結合されているため、ページの読み込み中に既にドラッグが発生していることがわかります。上記のユース ケースでデータベース設計を改善できる可能性について聞いてみるのもよいでしょう。すでにインデックスと FK が存在します。キャッシュはまだどこにも追加されていません。

4

1 に答える 1

2

これは、データをモデル化するためのかなり合理的なアプローチです。唯一のコメントは、参照テーブルの主キーに「REF_ID」という名前を付けるのではなく、テーブル自体にちなんで名前を付けるということです-たとえば、 award_id 。外部キーについても同様です。

もちろん、これは好みの問題ですが、より一貫性があります。ユーザー プロファイル テーブルの主キーに「profile_id」という名前を付けました。

最新のハードウェアでは、適切なインデックスがあれば、何億ものレコードを扱う場合を除いて、7 つのテーブルの結合がパフォーマンスの問題になることはありません。遅いクエリの EXPLAIN を投稿して、解決できるかどうか確認してください。

ただし、実際には、1 つの大きなクエリよりも、いくつかの小さなクエリを実行してページにデータを入力する方が簡単な場合があります。これは、もちろん、7 つのテーブルを結合すると、行ごとにすべての「1 対 1」のデータが繰り返されるためです。これにより、データ処理レイヤーが少し乱雑になるだけです。私は今それを想像しています、あなたは得ています

user_id user_name job_name language_name
-------------------------------------------
1      Bob         Waiter   French
1      Bob         Waiter   German
1      Bob         Waiter   Italian
1      Bob         Plumber  French
1      Bob         Plumber  German
1      Bob         Plumber  Italian

代わりに、1 回のクエリでユーザー プロファイルを取得し、2 回目でユーザーの仕事を取得し、3 回目でユーザーの教育などを取得します。これにより、PHP コードがよりきれいになり、データベースと Web アプリケーションの間でやり取りするデータの量が減ります。

于 2013-03-03T15:22:58.070 に答える