クラスター化列ストアインデックスと外部キー
インデックスを使用してデータウェアハウスのパフォーマンスを調整しています。私はSQL Server 2014にかなり慣れていません。マイクロソフトは次のように説明しています。
"クラスター化列ストアインデックスは、大規模なデータウェアハウスファクトテーブルを格納するための標準と見なされており、ほとんどのデータウェアハウスシナリオで使用されると予想されます。クラスター化列ストアインデックスは更新可能であるため、ワークロードは多数の挿入、更新、削除操作を実行します。 "http://msdn.Microsoft.com/en-us/library/gg492088.aspx
ただし、ドキュメントをさらに読むと、制限と制限が適用されます。
"一意制約、主キー制約、または外部キー制約を持つことはできません。"
これは私をとても混乱させます！さまざまな理由（データの整合性、セマンティックレイヤーで関係を表示するなど）のために、データウェアハウスに外部キーを設定することをお勧めします（必須ではありません）。
したがって、Microsoftはデータウェアハウスシナリオ用にクラスター化列ストアインデックスを推奨しています。ただし、外部キー関係は処理できませんか？！
これは正しいですか？他にどのようなアプローチを勧めますか？これまで、データウェアハウスのシナリオでは、クラスター化されていない列ストアインデックスを使用し、データの読み込みのためにドロップと再構築を行いました。ただし、SQL Server 2014はデータウェアハウスに真の新しい価値を追加しませんか？
ここにはたくさんの質問があります：
Q：（外部キーの欠如）私はよく混乱します！さまざまな理由（データの整合性、セマンティックレイヤーで関係が表示される、など）のためにDWHにFkを含めることは（必須ではありません）良い方法です
A：正解です。通常、データウェアハウスに外部キーを配置することをお勧めします。ただし、クラスター化列ストアインデックスはまだサポートしていません。
Q：MSはDWHシナリオのクラスター化列ストアインデックスを推奨していますが、FK関係を処理できませんか？！
A：マイクロソフトからツールが提供されます。これらのツールの使い方はあなた次第です。
最大の課題がデータウェアハウスのデータ整合性の欠如である場合、必要なツールは、外部キーを持つ従来のテーブルです。
最大の課題がクエリのパフォーマンスであり、ロードプロセスの一部として独自のデータの整合性を確認する場合、必要なツールはクラスター化列ストアインデックスです。
Q：ただし、SQL 2014はDWHに実際の新しい値を追加しませんか？
A：ありがたいことに、SQL Server 2014の新機能はクラスター化列ストアだけではありませんでした。たとえば、 新しいカーディナリティエスティメータを確認してください。
Q：なぜ私のお気に入りの機能が実装された方法にとても腹を立て、苦いのですか？
A：あなたは私を捕まえた-あなたは本当にその質問をしなかった-とにかく私はそれに答えよう。すべてが正確な仕様に基づいて構築されているわけではない、サードパーティソフトウェアの世界へようこそ。マイクロソフト製品に加えたい変更に情熱を傾けている場合は、 Connect.Microsoft.com をチェックしてください。これは、変更を送信して他の人が投票できるフィードバックプロセスであり、製品チームがそれを読んで、変更を実装しない理由を伝えます。時々。ほとんどの場合、彼らはそれを「修正しない、私のマシンで機能する」とマークするだけですが、ねえ、あなたはいくつかの答えを得ることがあります。
慣れ親しんでいる部分が欠けているように感じます。しかし、それは彼らが行方不明だからです。
それでも、SQL Serverは、外部キーが単なる概念（当時はトリガーによって実装されていた）であり、制約などの物理的な実装ではなかったときに、うまく使用されていました。宣言的参照整合性は少なくともSQL Server 7.0には存在しましたが、現在の実装よりもはるかに弱くなっています。
クラスター化されたColumnStoreインデックスの値に関しては、インデックスを提供し、行は更新可能です。この議論は価値があるかもしれません： http://sqlwithmanoj.com/2014/07/24/maintaining-uniqueness-with-clustered-columnstore-index-sql-server-2014/
Manojは、クラスタリングキーをPK（テーブル/ビューの最初の列）として、このテーブルの上にインデックス付き/マテリアライズドビューを作成する方法があることを指摘しています。もちろん、それがあなたに適しているかどうかは、あなたがしなければならない決定です。
しかし、Aaron BertrandとTomTomがコメントしたように、これはすべてパフォーマンスの向上に関するものです。あなたが関係する他の問題を管理できれば（そして私はそれらがは管理可能であると信じています）、あなたはかなりの数の利益を得ます。したがって、ができることのためにColumnStoreを使用し、不足している機能を自分で管理します。
この質問はSQL 2014に関するものですが、SQL 2016で列ストアインデックスに加えられた変更に照らして追加情報を提供したいと思います。異なるバージョンでの制限を整理するのは難しい場合があり、この質問はまだGoogleでかなり高くなっています。
SQL 2016の場合、Microsoftは、非クラスター化btreeインデックス（クラスター化列ストアテーブルにセカンダリインデックスとして追加できるようになりました）を使用して外部キー制約を適用する方法について説明しています（列ストアインデックスの前に制約が追加されている場合）： https ：//docs.Microsoft.com/en-us/sql/relational-databases/indexes/columnstore-indexes-design-guidance
Niko Neugebauerもこれについてブログ投稿しています。実際に列ストアテーブルに一意の制約を作成することは可能です（私は自分の仕事でこのアプローチを適用しています）： http://www.nikoport.com/2015/09/15/columnstore-indexes- part-66-more-clustered-columnstore-improvements-in-sql-server-2016 /