2

1 つのテーブルを持つ SQL Mobile データベースがあります。有用で頻繁にクエリされるデータを含むいくつかの列と、頻繁にクエリされないレコードごとに比較的大きな文字列 (1000 文字以上) を格納する 1 つの列があります。

この偽のスキーマを想像してみてください。「lifeStory」フィールドは大きなものです。

table1
String firstName
String lastName
String address
String lifeStory

代表的なクエリは

SELECT firstName, lastName, address FROM table1 WHERE firstName = :p1

このテーブルに大きな、あまりクエリされない列を残しておくと、パフォーマンス上の懸念があることを知っている人はいますか?

4

2 に答える 2

3

そのフィールドのデータを実際に表示/クエリしようとしない限り、パフォーマンスの低下に気付かないはずです。

于 2008-11-12T17:04:35.987 に答える
3

VS2005 (c#) および SQLServerCE ライブラリを使用すると、パフォーマンスに影響を与えることはわかりますが、その理由を正確に答えることはできません。 さらに、実際には、列自体ではなく、その列のデータの長さがパフォーマンスに悪影響を及ぼします。

仕事用のプロジェクトで独自のパフォーマンス テストを行っているときに、同様のシナリオに出くわしました。

table1

c1 NVARCHAR (20)
c2 NVARCHAR (20)
c3 NVARCHAR (20)
c4 NVARCHAR (20) 
c5 NVARCHAR (4000) //maximum allowed and fully populated for testing purposes

走れば…

select c1, c2, c3, c4 From table1

...約1560ミリ秒かかります。

2 つのテーブルを作成し、大きな列を引き出して (そして、2 つを関連付けるための外部キーを自然に提供して)、最初のテーブルで同じクエリを実行すると、約 660 ミリ秒かかります。

最後に、他のテストでは、列の数ではなく、各行のデータのサイズであることがわかりました。つまり、5 列、2 文字幅 == 2 列、5 文字幅。また、必ずモバイル デバイスでこれらを実行してください。これらを単体テストすることはできますが、私の PC の処理能力が大幅に向上したため、上記の 1000 ミリ秒近くではなく、10 ～ 20 ミリ秒のタイミング差が見つかりました。

なんで？これはあくまでも推測ですが…

モバイルの世界では、DBMS がまったく同じというわけにはいきません。エンタープライズ データベースではありません。隠れたところで、彼らはまだ OLEDB の「シーク」を行っているに違いありません。

全体として、モバイル空間では、DB を最も「正規化」するのではなく、最も頻繁なユース ケースをサポートするように設計することを学びました。幸運を！

于 2008-11-25T18:32:52.897 に答える