データウェアハウスのインデックス作成アプローチ-検証する
以下のデータウェアハウスのインデックス作成（SQL Server 2014 SP1 Ent）に対する私のアプローチを見て、それが正しいか、変更する必要があるかを教えてください。 （ほとんどの場合、データウェアハウスはSSAS Cubeに使用され、場合によっては直属の部下に使用されます）
私のインデックス作成アプローチ：
- （ディメンションテーブル内の）すべての主キーには、クラスター化されたインデックスがあります
- より大きなディメンションテーブル（5万行以上）の場合、頻繁に使用する列ごとに専用の非クラスター化インデックスがあります
- すべてのファクトテーブルには、PKクラスター化インデックスが実装されています（FactTableKeyのような単一の非FK列に）–しかし、これはそこに配置すべきではありません。
- （ファクトテーブル内の）すべての外部キーには、専用の非クラスター化インデックスがあります（その中の1つのFK列ごとに）
- さらに、すべてのFKの多くの非クラスター化インデックスではなく、ファクトテーブルにCLUSTERED COLUMNSTORE INDEXを実装することを検討していますが、この場合、これは推奨されないソリューションであると判断しました。
さらに、Visual Studio SSDTを使用したテストラボで、FILEGROUPに属するファクトテーブルにCCIインデックスを配置しようとしましたが、FILEGROUPに属するテーブルでCCIを使用できないという情報でエラーが発生します。奇妙なことに、SSMSからそのようなCCIを直接作成できます。 Visual Stusioの問題またはSSMSのバグ？
ファクトテーブルの外部キーごとに単一列のインデックスを追加したとのことですが。多くの場合、少なくとも一部の外部キーはカーディナリティが低いため、それ自体ではインデックスに役立たない可能性があります。 https://www.ibm.com/developerworks/data/library/techarticle/dm-1309cardinal/
これらは、ユーザーがテーブルをクエリする方法に基づいて設計できる複数列のインデックスの一部としてより役立つ場合があります。
ワークロードがそれに適している場合は、非クラスター化列ストアインデックスを大きなディメンションテーブルとファクトテーブルで検討する必要があります。これらは、データウェアハウスのワークロードに最適です。 http://www.nikoport.com/2016/03/07/columnstore-indexes-part-79-loading-data-into-non-updatable-nonclustered-columnstore/
2014を使用しているため、制約やその他のインデックスを保持する場合は、非クラスター化が唯一のオプションです。