0

顧客調査アプリケーションに関連するデータを保存する必要があるデータベーステーブルのパフォーマンスに関心があります。

調査からの顧客の回答を格納するデータベーステーブルがあります。調査の質問は顧客iに応じて変わるため、各質問IDを列として使用してテーブルスキーマを定義する代わりに、次のように定義します。

    customerdata(customerid  varchar, 
         partkey varchar, 
         questionkey varchar, 
         value, varchar,
         version, int,
         lastupdate, timestamp)

どこ：

partkey：パーツのショートコードです（part1、part2 ...）

質問キー：年齢、性別などの質問のショートコードです

一部のお客様はアンケートに2回記入するため、3回など、バージョン列を追加しました。

この設計では、customerid、partkey、questionkey、およびversionが主キーです。

そのようなデザインでのパフォーマンスが気になります。他の主キーをインデックスとして定義する必要がありますか？それは役に立ちますか？これまでのところ、30人の顧客に対して7000件のレコードがあります。私は最大300-500を期待しています。どう思いますか ？

4

2 に答える 2

1

かなり小さなデータベースのように聞こえます。パフォーマンスの問題が発生することはないと思いますが、、、またはそれ以降のクエリpartkeyで何かを検出した場合は、いつでも1つ以上のインデックスを追加して、その時点で問題を解決できます。あなたが持っていない、そしておそらく決して起こらないであろうパフォーマンスの問題を解決する必要はありません。questionkeyversion

customeridパフォーマンスの問題は、フィールドをプライマリフィルターとして使用しない時間に敏感なクエリを実行する必要がある場合にのみ発生します。（顧客間でデータを集約したい場合）そのようなクエリがあると思いますが、そのようなクエリから予想される1秒以下の応答時間の影響を受けるほど時間に敏感であるとは思えません。データの小さなコレクション。そうである場合は、インデックスを追加します。

また、テーブルには1つのPRIMARYKEYしかないことに注意してください。そのキーは複数の列を使用できるため、列、、、customeridおよびは主キーの一部であると言えますが、すべての「主キー」を言うことはできません。partkeyquestionkeyversion

于 2012-10-09T21:55:28.173 に答える
-1

行番号に関しては、100.000行を超えるmysqlデータベースを経験しましたが、問題なく動作するので、大丈夫です。

ただし、複雑なクエリを実行する場合は別のケースになります。これは、行番号ではなくデータベースの設計に依存します。

于 2012-10-09T21:42:59.567 に答える