私は、ログオンが電子メールで行われ、メンバーが自分の名前/ニックネームを変更できるコミュニティサイトを構築しています。
メンバーテーブルのメンバー名/ニックネームをメンバーの他のプロパティと一緒に保持するか、別のテーブルを作成し、そのテーブルにメンバー名/ニックネームを書き込んでメンバーのIDを関連付ける必要があると思いますか。
私は2番目のオプションを支持しています。なぜなら、そこからメンバー名を取得する方が速いと思うからです。
それは正しい/より良い方法ですか？
更新：他のテーブルの理由は、さまざまなセクションのユーザー名を取得する必要があるためです。たとえば、フォーラム。fromトピックの各投稿のユーザー名ごとに小さなテーブルをクエリする方が速いのではないでしょうか。
私はそれを1つのテーブルに保ち、そのテーブルの電子メールに一意の制約を設定します。
別のテーブルを追加することの利点は1つもわかりません。
最初のオプションを選択します。名前/ニックネームをmembersテーブルに保持します。この場合、追加のテーブルとそれに伴う結合のオーバーヘッドを導入する必要はありません。
なぜ2番目のオプションの方が速いと思いますか？
ニックネームがメンバーIDとの1対1の関係である必要がある場合、それらを保存する適切な場所は同じテーブルにあります。これはまだインデックス付きの単一レコード検索であるため、他のオプションとほぼ同じくらい高速である必要があります。
実際、他の情報を取得するのと同じSELECTでニックネームを取得できるため、このソリューションの方がおそらく高速です。
質問の更新に回答するための更新：
2番目のテーブルは、行数の点でこれより小さくはありません。SQL検索の主な要因は、1）テーブル内のレコードの数、および2）検索のインデックス付き部分からの一致の可能性の数です。
この場合、小さいテーブルのレコード数は大きいテーブルとまったく同じになります。また、メンバーIDは一意であるため、インデックスによって返される一致する可能性のあるレコードの数は常に1になります。
検索しているテーブルの列の数は、通常、データを返すのにかかる時間とは無関係です（SELECTステートメントに実際にリストする列の数が影響する可能性がありますが、どのテーブルを使用していても同じです。検索）。
SQLデータベースは、データの検索に非常に優れています。データを正しく構造化し、データベースにデータを戻すことを心配させます。彼らが言うように、時期尚早の最適化はすべての悪の根源です。
はい、メンバーのIDを他のプロパティに関連付けるのが正しい方法です。
名前にインデックスを作成するだけで、クエリを高速化できます。