2

これまでに構成したのは、各ユーザーが一意の を持つユーザーのテーブルだけですuser_id。ただし、各ユーザーの連絡先のリストを保存する必要があります。これには、各連絡先の user_id のみを含める必要があります。しかし、私は設計上の課題に直面しています。

ユーザーの連絡先リストを格納するテーブルをユーザーごとに作成する必要がありますか? これはスケーラブルなソリューションですか?

または、次のような2 つの列user_idを持つ 1 つのテーブルを作成する必要があります。contact_id

------------------------------------
| | ユーザー ID (整数) | contact_id (整数) |
------------------------------------
| | 10001 | 9945 |
| | 10001 | 2239 |
| | 10002 | 9636 |
------------------------------------

SELECT * FROM contacts WHERE user_id=10001;2 番目のオプションを使用した場合、すべてのエントリを毎回反復処理する必要があるため、一意のインデックスの欠如とテーブルの膨大なサイズが最終的にうまくいくのではないかと心配しています。

これらのデータを整理する最善の方法は何ですか?

4

3 に答える 3

3

単一の正規化されたテーブルは絶対に正しいアプローチです。

「インデックスの欠如」が懸念されるため、パフォーマンスが心配です。

索引付けの欠如？索引付けがないのはなぜですか?

主キーを作成します(user_id,contact_id)(これは意味的に意味があり、すべてです)。必要なのはそれだけです。

可変数のテーブルを持つことは決してありません。「ユーザーごとのテーブル」は、私のチームから追い出されたときです。;)

于 2013-07-18T22:15:20.127 に答える
1

「ピボット」テーブルを使用する 2 番目の方法は、正規化の最良の方法であり、ベスト プラクティスです。また、適切なテーブルと列へのインデックスとの外部キー関係を作成することもできます。

于 2013-07-18T22:12:20.813 に答える
0

2 番目のオプションを使用した場合、一意のインデックスが作成されず、テーブルのサイズが非常に大きいため、最終的には SELECT * FROM contact WHERE user_id=10001; でさえ作成されるのではないかと心配しています。すべてのエントリを毎回繰り返す必要があるためです。

user_id のインデックスは、この問題を解消します。反復するのではなく、多数のレコードに対しても適切に機能する検索アルゴリズムを使用します。クラスター化インデックスwhere user_id=が最も一般的な種類のクエリである場合は、パフォーマンスがさらに向上します。

最初のオプションであるユーザーごとのテーブルは、これまでにない最悪の方法です。

于 2013-07-18T22:15:12.617 に答える