SQLテーブルデザインのアドバイス

Question

私は、ログオンが電子メールで行われるコミュニティサイトを構築しており、メンバーは名前/ニック名を変更できるようになります。

メンバーの他のプロパティを使用してメンバーの名前/ニック名をメンバー名に保持するか、別のテーブルを作成する必要があると思いますか、そのテーブルにメンバー名/ニック名を書き込み、アソシエイトメンバーのIDを作成します。

私は2番目のオプションを支持しています。なぜなら、メンバーの名前をそこから引き出す方が速いと思うからです。

それは正しい/より良い方法ですか？

更新：理由は他のテーブルのために、さまざまなセクションのユーザー名をプルする必要があるということです。たとえば、フォーラム。トピックからの各投稿の各ユーザー名の小さなテーブルをクエリする方が速くないでしょうか？

Answer 1

なぜ2番目のオプションがより速くなると思いますか？

ニックネームがメンバーIDに必要な1対1の関係である場合、それらを保存するのに適切な場所が同じテーブルにあります。これは依然としてインデックス付きの単一録音検索であるため、他のオプションと同じくらい速くないはずです。

実際、このソリューションはおそらくより速いでしょう。 同じ 他の情報を取得するときに選択します。

質問の更新に答えるための更新：

2番目のテーブルは、行数に関しては小さくありません。 SQL検索の主な要因は、1）テーブルの記録の数と2）検索のインデックス化された部分からの一致の可能性のある数です。

この場合、小さなテーブルのレコードの数は、より大きなテーブルとまったく同じです。また、メンバーIDが一意であるため、インデックスによって返される可能なマッチングレコードの数は常に1になります。

検索しているテーブルの列の数は一般に、データを返すのにかかる時間とは無関係です（選択ステートメントに実際にリストする列の数は効果がありますが、それはあなたがどのテーブルに関係なく同じです検索）。

SQLデータベースは、データを見つけるのに非常に優れています。データを正しく構成し、データベースに戻すことを心配させます。彼らが言うように、早期最適化は、すべての悪の根源です。

Answer 2

私はそれを1つのテーブルに保ち、そのテーブルの電子メールに独自の制約を設定します。

別のテーブルを追加する際には、単一の利点がありません。

Answer 3

最初のオプションを使用してください：メンバーテーブルに名前/ニック名を保持します。この場合、追加のテーブルとそれに伴う結合のオーバーヘッドを導入する必要はありません。

Answer 4

はい、メンバーのIDを他のプロパティに関連付けることが正しい方法です。

名前にインデックスを作成して、クエリをスピードアップするだけです。