我應該將 nvarchar(max) 維度放在我的數據倉庫中的什麼位置？
我正在為一個新的數據倉庫設計 ERD。
- SQL 伺服器 2016
- “事實”表的聚集列儲存索引
- 鬆散星型模式
我將“事實”放在引號中並說“鬆散星型模式”，因為使用聚集列儲存，我可以將許多維度直接放入“事實”表中，而無需擔心行寬的典型問題。我的許多維度都進入了“事實”表。我正在創建一些維度表和代理鍵，但前提是除了暗淡描述本身之外，暗淡還具有屬性。
這讓我想到了一些非常廣泛、高基數的領域，即
nvarchar(max). 無需太深入，將這些欄位視為非規範化列表。我需要針對我的一個數據源的粒度對列表進行非規範化。我確實在另一個事實表中對其進行了規範化，但我沒有在這個數據源中顯示它。使用者需要這些欄位來搜尋我正在呈現的數據集市中的關鍵字。在我目前的設計中，它們位於聚集列儲存“事實”表中。使用者會頻繁地查詢事實表而不接觸
nvarchar(max)欄位。有沒有地方可以將比聚集列儲存表更正確的寬維度放入我的數據倉庫中？
Joe Obbish告訴我，我們目前無法
nvarchar(max)加入 CCI。創建一個 LOB 表作為我的“事實”表的擴展對我來說是最佳實踐嗎？我們將來可能會添加其他語言。目前，在可預見的期限內，該
nvarchar列僅包含英語。
Microsoft 建議對大型數據倉庫表使用 CCI，但需要注意以下幾點：
在以下情況下不要使用聚集列儲存索引：
- 該表需要 varchar(max)、nvarchar(max) 或 varbinary(max) 數據類型。或者，設計列儲存索引，使其不包含這些列。
簡而言之，您的選擇是完全放棄列儲存，在不包含該
VARCHAR(MAX)列的表上創建非聚集列儲存索引，或者將 LOB 列移動到單獨的表中。您說最終使用者有時會在不查詢VARCHAR(MAX)列的情況下訪問表，所以我會盡可能嘗試使用列儲存，這樣這些查詢就可以獲得全部好處。如果我正在設計這個，我的第一次嘗試是使用包含除列之外的每一列的非聚集列儲存索引來測試您的工作負載
VARCHAR(MAX)。這是一個單獨的索引，因此您將為列產生額外的儲存空間，但如果您看到典型的 CCI 壓縮比，它只會額外增加 10%。這是最簡單的設計，可以讓您很好地利用 SQL Server 2017 的可用性來將VARCHAR(MAX)列包含在聚集列儲存索引中。Niko Neugebauer 寫了一篇關於在 SQL Server vNext 中使用 LOB 數據對 CCI 進行一些測試的部落格文章，您可以在此處找到。