SQL挿入のパフォーマンスの問題

Question

私は、この表の電話帳SQL Server 2005を持っている：

username(PK) Serial(PK) contact_name contact_adr  contact_email contact_phone 
bob   1   Steve   12 abc street steve@bb.com 1234   
bob   2   John   34 xyz street john@bb.com 5345   
bob   3   Mark   98 ggs street mark@bb.com 1234   
patrick  4   lily   77 fgs street lily@bb.com 1234   
patrick  5   mily   76 fgs street mily@bb.com 1234   
von   8   jim   6767 jsd way  jim@bb.com  4564   

今、あなたが一緒に同じユーザの電話帳の店舗すべての連絡先を見ることができます。 この方法を保存することで回避できない利点があります。

私の質問は： 私はすべてのユーザーのテーブルに1億のエントリがある場合、上記のテーブルに私の将来の挿入は非常に高価でしょうか？私は100万行でテスト

SQLエンジンがデータを入力するために、実際の場所を見つける必要があるので、（私はその名の下に意味）

、私は顕著な問題が表示されません。

私にこの経験や提案があるかどうか尋ねていますか？

おかげ

Answer 1

は、DB設計の第一原理の一つは、データ非冗長です：あなたは何度も同じデータを繰り返してきたように、あなたのdbテーブルのデザインは、その原則に準拠していません。共鳴可能なソリューションは、ユーザー用の別個のテーブル、連絡先用の別個のテーブル、およびユーザーと連絡先間の実現のためのテーブルを作成することです。

Answer 2

これは、基になるデータベースによって異なります。あらゆる実装には、そのスリーブの下で異なるものがあります。

しかし！そのテーブルでインデックスを使用し、その内部に多数の、多くの、多くの、多くの行がある場合、パフォーマンスはほぼ確実に損なわれます。

Answer 3

まず、ユーザー名は、自分のテーブルのプライマリキーではないようです。あなたはおそらくそれを動作させたい場合は、別のフィールドと組み合わせて使用​​する必要があります。この時点では、私はむしろあなたのserial列をプライマリキーとして使用し、クエリにのを得るためにusernameのインデックスを持っています。

テーブルのサイズが大きくなると、挿入が確実に遅くなります。しかし、私はこのアプローチに従うのが遅すぎるとは思わない。

Answer 4

強制的にデータを格納することはできません。挿入時にシリアルを再シーケンシングしていますか？データが「一緒に保存」されていることをどのように確認していますか？

このすべてのデータを1つのテーブルに入れることは、実際にインデックス構造に依存します。テーブルの索引が増えるほど、挿入時に処理が多くなります。ユーザテーブルは通常クエリが頻繁に実行され、（比較的）挿入されることはめったにないため、インデックスは頻繁にインデックスされるため、挿入が遅くなる可能性があります。答えは、ほぼすべてのDB質問と同様に、「それは依存している」です。

Answer 5

アドレス帳に最適なアプローチは、NOSQLハッシュテーブルです。 PKのインデックスは必要ありません。アルゴリズムは、PKによって識別された行が見つかる「ページ」を返します。ユーザのアドレス帳はまた、非正規化された関係として、ユーザと共に格納される。インサートのオーバーヘッドはごくわずかです。 Hashed-PKは、PKがわかっているときの挿入/検索用に最適化されています。 OLTPシステムに最適です。今、誰が誰を知っているかを把握して、特定のユーザーの連絡先を他のすべてのユーザーの連絡先に関連付ける必要があるようにする場合は、別の種類のワームがあります。ただし、特定のユーザーの連絡先がそのユーザーに「プライベート」なままである単純なアドレス帳アプリケーションでは、ハッシュされた主キーシステムが優れています。