アプローチで考慮すべきこと
ユーザープロファイルをユーザーテーブルに保存する
- ここには冗長なデータがたくさんある場合がありますが（情報が含まれていない可能性がある列）、これは通常、プロファイルデータを取得するという点で最速のアプローチになります。
- クイック（特に、データベースから必要な列のみをプルする場合）
- 無駄なデータ
- 操作/保守がより困難（おそらくPHPMyAdminなどのインターフェイスを使用）
User_Profileにユーザープロファイルを保存する表1-1ユーザーとの関係
- 結合はまだ非常に高速である必要があり、ユーザーが入力しない限りユーザープロファイルが作成されない場合は、データの冗長性を排除できます。
- 操作が簡単
- 参加（または2番目のクエリ）のために少し遅くなります
ユーザープロファイルをプロパティおよび値としてテーブルに保存する
*つまり可能なオプションを格納するテーブル、user_id、option_id、およびvalueを格納するテーブル*
- 冗長なデータは保存されていません。すべてのデータが関連しています
- 最も正規化された方法
- データの取得と更新が遅い
私の印象では、ほとんどのWebサイトは2番目の方法を使用し、プロファイル情報を2番目のテーブルに格納します。これは、ほとんどの大規模なWebサイトがデータベース（twitter、facebook）を非正規化して、書き込みパフォーマンスを低下させながら読み取りパフォーマンスを向上させるのが一般的です。
50,000件のレコードを表示している場合は、プロファイル情報を2番目のテーブルに保持することが道のりだと思います。最適なパフォーマンスを得るには、キャッシュが効果的に機能するように、大量に書き込まれるデータと大量に読み取られるデータを分離しておく必要があります。