5

私たちは若い専門家向けのウェブ製品を持っており、彼らに彼らの専門家としてのアイデンティティを示すために彼らのページを作成する可能性を与えています。したがって、users資格情報を含むユーザーに関する情報（電子メール、パスワード、名前）とページに関する情報（プレミアムかどうか、ページアドレス、テーマ）の両方を含むテーブル

今、私たちは、採用担当者が候補者を閲覧するために私たちのプラットフォームにサインアップする可能性を提供したいと思います。リクルーターはページを持つユーザーになることもできますが、そうする必要はありません。

今私たちの2つのアプローチ：

A /recruiters採用担当者の名前と資格情報、およびサイトを作成した場合はテーブルのuser_idに接続する列を使用してテーブルを作成します。IDusers

  • 利点：製品は、2つの異なるチームによって別々に簡単に開発できます。
  • 不便：採用担当者がユーザーでもある場合、名前と資格情報が重複します。1つが更新されたときに両方のクレデンシャルを更新するか、2つの異なる電子メール/パスワードの組み合わせを使用できるようにする必要があります。1つはユーザーアカウント用、もう1つはリクルーターアカウント用です。

データベース構造：

users
ID name email password group_id premium theme page_address

recruiters
ID name email password company_id user_id

B /採用担当者を別のusersテーブルに追加group_idし、ユーザーページに関するすべての情報（プレミアムかどうか、ページアドレス、テーマ）を別のテーブルに移動します。また、採用担当者用に、特定の情報を含む3番目のテーブルがあります。

  • 利点：すべての資格情報を含む1つのテーブル。
  • 不便：数百万人のユーザーにリーチする場合、採用担当者間のクエリは、巨大なテーブルの中から小さなサブセットを取得する必要があります。また、すべてのユーザーのサイト情報を取得するために多くの参加があります。

データベース構造：

users
ID name email password group_id

pages
user_id premium theme page_address

recruiters
user_id company_id

C /他の解決策はありますか？

ご入力ありがとうございます！

トリスタン

4

1 に答える 1