soCaseInsensitiveは、TdxMemDatasetのTdxMemIndexのパフォーマンスに大きく影響しますか？

Question

パフォーマンスを改善するために、DevExpress TdxMemDataset にいくつかのインデックスを追加しています。 TdxMemIndex には、 soCaseInsensitive のオプションを含む SortOptions があります。私のデータは通常GUID文字列なので、大文字と小文字は区別されません。すべてのデータを同じケースに強制するのが良いのか、 soCaseInsensitive フラグとLocateの呼び出しで loCaseInsensitive フラグを使用するのがマイナーなのかパフォーマンスの低下（インデックスを使用する必要があるたびに文字列の大文字小文字を変換することにほぼ等しい）。

この時点で、CaseInsentiveをオフにして、大文字と小文字を変換しています。

Answer 1

IMHO、最善の方法は、投稿時にデータ品質を保証することです。理由：

1. あなたは（通常）データの性質を知っています。たとえば、 TdxMemDataSetなどの一般的なコンポーネントが使用を強制される much より遅いAnsiUpperCaseの代わりに、UpperCaseを使用できます（GUIDはすべてASCII範囲であることを認識しています）。

2. データは一度だけ入力します。 TdxMemDataSetの内部上位エンジンを暗示する検索/並べ替え/フィルタリングは、繰り返されるアクションです。また、実現せずにこのエンジンをトリガーする他の連鎖アクションがあります。 （例：デフォルトで並べ替えられ、GridMode：= True（DevEx。コンポーネントを使用していると仮定します）を持つソートされたTcxGridと、基になるデータセットに並べ替えメッセージを渡すブローカーのように動作するクラスがあります。

3. 通常、データ入力は、バッチで1つまたはいくつかのレコードのステップで実行されます。唯一の注目すべき例外は、データ取得アプリケーションです。ただし、どちらの場合も、ユーザーの使いやすさの文化により、方法で応答時間が長くなります。 （0.005ミリ秒続くレコードポストにUpperCase呼び出しをどれだけ追加しますか？）OTOH、ユーザーはデータ検索操作（検索、ソート、フィルタリングなど）の速度に非常に厳しいです。データの取得を可能な限り高速に保ちます。

4. データベース内のデータを公開する準備ができていると、他のモジュールを書くとき（ if 書くとき）にエラーを処理するリスクが減ります（AnsiUpperCaseを覚えておく必要があります作成する言語のモジュールのデータ）。また、ここでの古典的な例は、他の外部ツールを使用してデータにアクセスする場合です（たとえば、dbマネージャーがデータに対してSQL SELCTを実行する場合）。

hth。

Answer 2

たぶん、DevExpressフォーラム（または、アクセスできる場合はサポートメール）が、パフォーマンスに関する質問に対する信頼できる答えを探すのに適した場所です。

とにかく、データがあなたが望むフォーマットにあることを保証する方が良いです-すでに説明した理由のために-あなたがそれを保存する瞬間。そのため、具体的には、GUIDが大文字（または、好みの問題）で書かれていることを確認してください。 guidデータ型を持つのがSQL Serverまたは別のデータベースサーバーである場合、SELECTが機能することを確認します-適用可能で可能であれば、さらにはソート。