私の直感では、文字列 (配列要素を含む) フィールドをテーブルのインデックスとして設定すると、パフォーマンスが低下します (テーブルで実行される操作の大部分が挿入と更新である場合、テーブルにはトランザクション データとその現在のサイズが保持されます)。約 20 ミルのレコードです)。
文字列は 4 つの配列要素で型を拡張しますが、すべての要素が常に入力されるわけではありません。このフィールドをインデックスの 1 つとして設定しない理由を説明する必要があります。私は答えを探したり、Kimberley Tripps のブログを読んだり、MSDN のインデックスに関するベスト プラクティスを調べたりしました (インデックスは最初に数値、次に文字列フィールドに最適であるとのみ言及しています) など。つまり配列型です。文字列配列フィールドにインデックスを付けないことを正当化する理由を教えてください。そして、私の勘が完全に間違っていて、インデックスが配列フィールドでうまく機能するのであれば、なぜそうなるのでしょうか?
@ 10pが指摘したように、sayDimensionを唯一のフィールドとして追加すると、すべての配列要素のインデックスが作成されます：Dimension、Dimension2_、Dimension3_（SQLテーブルフィールドの名前）。
このようなインデックスの値は、実行されるクエリによって異なります。Dimension[3]クエリされただけの場合、は不明であるため、インデックスは価値がDimension[1]ありDimension[2]ません。
これは、配列要素ごとにインデックスを作成することで解決できます。次に例を示します。
インデックスフィールドのコンボボックスを使用して、個々の配列要素を選択できます。
このようなインデックスの値は、追加の挿入コスト（および配列値が変更された場合は更新）に対して重み付けする必要があります。
ArrElement3つの追加の配列要素、、をArrElement2含むArrElement3拡張データ型があるとしますArrElement4。AXでこのタイプのフィールドをArrElement使用してインデックスを作成すると、SQL Serverに4つのフィールド（ArrElement、ArrElement2、ArrElement3、およびArrElement4-の順序で）を持つインデックスが効果的に作成されます。インデックス内の配列要素の順序を変更することはできませんが、私の意見では、そのようなインデックスが本当に目的にかなうのであれば、そのようなインデックスを使用しても問題はありません。それがあなたの質問に答えることを願っています。
メモまたはオブジェクト フィールドは、AX のインデックスの一部にすることはできません。
さらに、ntext、text、またはimageデータ型で構成される列は、SQL Server のインデックスの列として指定できません。