2011-09-26 56 views
3

我們正在設計一個大容量SQL Server應用程序,該應用程序涉及處理和報告限定在指定年份內的數據。想到年份時使用分區。按年分區與名爲Data_2011,Data_2010等的單獨表分區

另一個建議是以編程方式創建單獨的物理表,其中名稱的後綴是年份,並且在多年需要報告時提供物理表的聯合視圖。

我的直覺告訴我,這種情況是設計要處理的分區。使用其他方法有什麼好處嗎?

+5

我推薦後一種方法的唯一情況是,如果你不是企業版(你不能在標準等使用分區)。 –

+0

亞倫是對的。分區本質上是幕後的第二種方法,但服務器引擎爲您處理所有邏輯。 – JNK

+2

不要創建襪子傀儡帳戶,然後upvote您的主要帳戶與他們。我正在刪除Velika2並重新計算您的聲譽。 –

回答

3

從內部角度來看,方法基本上是一樣的。

在幕後,當您創建基於日期的分區時,SQL引擎爲每個分區創建單獨的物理表,然後在查詢表本身時執行基本上爲UNION的操作。

如果您在與分區字段相對應的分區表上查詢時使用了一個過濾器(例如DateField),那麼引擎可以直接進入數據所需的分區。如果不是,則根據需要在邏輯表中搜索每個物理表以完成查詢。

如果您的查詢將涉及日期過濾器(這聽起來像他們會從你的問題),那麼我可以認爲你的「自定義」方法沒有好處。

從本質上來說,您需要做出的選擇是您是否想要負責分區中涉及的所有邏輯和轉角情況,或者相信幾十年來一直在爲您做這些工作的開發人員?

對於我自己來說,如果有一個內置的框架的東西,我想要做的話,我總是嘗試使用它。與「自己動手」的解決方案相比,它總是更快,更穩定,更不容易出錯。

+0

如果使用分區的辦法,我想人們必須求助於動態SQL,因爲表的名稱都必須動態構建(加上當年的後綴名),除非當年總是存儲在一個後綴少表。所有這些使用名稱的手冊雖然不那麼複雜,但卻增加了手動維護,並使分區方法看起來更合適。我沒有看到爲什麼按日期劃分(正如在一個答案中解釋的那樣)是不合適的。這個場景似乎是我看到的分區的理想候選者。 – ChadD

+0

@Chad - 你從分區得到的唯一好處是維護相關的 - 更容易換出和數據集等。如果它一定會成爲一年一度的盛事,它可能不值得。 – JNK

+0

@JNK - 唯一的好處不是維護如果您使用的是企業版相關(http://technet.microsoft.com/en-us/library/cc645993.aspx |可擴展性和性能 - >分區表並行),那麼查詢計劃程序應降低查詢成本(http://msdn.microsoft.com/zh-cn/library/ms345599.aspx) – yucer

-4

我覺得使用日期驅動的分區鍵進行分區就像使用錘子來驅動螺桿一樣......'這一定是他們發明錘子的原因'......當需要並行進程來分區時像在數據集市中一樣運行,或者在某些任意鍵上進行分區,例如和身份專欄。就你而言,業務需求僅僅是保持多年的歷史。爲了使用分區,應用程序團隊需要創建一個動態生成分區約束的例程,這是DDL,是DBA團隊的責任。多表/聯合視圖提供了更簡單的解決方案。

+0

@查德:不,這是垃圾。 – gbn

+0

如果沒有分區,您必須根據搜索日期的範圍爲該實體生成查詢。它會爲該實體生成大量UNION,如果您想要與其他表連接,查詢會變得越來越重,並且應該爲所有情況動態生成。 從維護的角度看,你將不得不執行插入時給自己定位數據在正確的表,你必須檢查參照完整性與其他表,複製限制......所有你能做的只有一個分區表。 – yucer

0

這兩種解決方案都意味着您必須在db中執行一些元數據操作。問題是您是否會對歷史數據做一些更改/更新?我正在研究類似的解決方案 - 而不是一年我們正在工作半年的數據。在這種情況下,我們使用按日期劃分 - 我們有半年的浮動窗口保留兩年的歷史數據+當前半年(HTD)在10個分區(每個分區代表一個單獨的一個季度)。我們每天更新HTD數據,每週一次我們正在重申一些歷史數據。在這種情況下,我們僅擊中了幾個分區(分區ID在where子句中定義,分區鍵是在我們的一個維度中表示日曆日期的date_id)。整個桌子有大約250米的排。每半年這個過程都在調整分區,但同樣你必須處理這個視圖。使用這種方法,我們總是可以對整個表執行更新(使用您必須測試更新方案的視圖或針對單獨的表運行更新)。我們有適當的程序可以截斷/切換出表格的指定分區,因此操作很快。

很難說哪個是最好的選擇。但總的來說,如果你真的沒有改變歷史,我會建議使用這些表格(我會爲歷史記錄分配一個表格,爲當前數據分配一個表格)