2013-08-06 70 views
5

我打算使用SQL Server爲我的應用程序存儲XML BLOB。我正在努力進行設計決策,並尋找有關本主題經驗豐富的人的指導或建議。設計表來存儲SQL Server 2008 R2中的XML數據

需要作爲XML存儲的數據有大約100個簡單的數據點。它們可以很容易地分成每組20個數據點。在將來的應用程序版本中,我們計劃通過添加新的數據點來增加數據的範圍,其中一些將是分層的(列表,字典等)。

我們不預期需要對XML數據執行查詢。最多他們將是非常簡單的查詢,如果需要,我們可以將任何數據點提升到關係列。

我不確定是否應該創建一個巨大的XML BLOB來保存所有這些數據,或者是否應該將其分解爲多個XML列。在SQL Server 2008 R2中是否有任何有關處理XML數據類型的最佳實踐或準則可以幫助我做出最佳決策?它甚至重要嗎?

編輯:我已經設置使用XML作爲數據類型,我試圖做出是否我應該使用一個大的BLOB或將其分解成多個XML列的決定。

+0

你見過? http://msdn.microsoft.com/en-us/library/hh403385.aspx –

+0

Mikael,我已經讀過這個了。不過,我仍然不確定是將我的xml分解成多列還是隻有一個巨大的blob。我知道有一個2GB的大小限制,但我不擔心達到這個限制。有一段關於XML粒度的部分我認爲涉及到了我的問題,但說實話我已經多次閱讀過它,但我仍然不知道要走哪條路。 –

+1

如果邏輯上有一個XML列,那麼你應該這樣做。關於粒度的鏈接中提到的內容與在更新時鎖定一小部分數據的行上分割XML的影響有關。使用更多的列對鎖定沒有任何影響。當您使用XML索引時,更新XML的一部分時,該鏈接還提到了優化,並且在不更新列時不應該更快地更新。 –

回答

6

是的,它很重要!當你在SQL Server中存儲一個大的XML blob爲XML數據類型時,它不會被存儲爲文本塊 - 它被「解析」和「標記化」,並且以比使用varchar(max)來存儲文字表示。

如果它真的看起來像XML,聞起來像XML和庸醫般的XML - 然後肯定USEXML數據類型!

更新:如果你只是打算存儲和檢索整個XML - 我沒有看到任何好處把它分解成塊。 SQL Server中的XML數據類型最多可以容納2 GBy數據(就像varchar(max)一樣),並且您不會看到存儲(和檢索)多個較小XML片段的任何性能提升。

+1

看來這個問題不是關於'XML'與字符串類型,而是_one巨大的XML_與_multiple [更小的] XML_ –

+0

@ i-one這是絕對正確的。 –

+1

@DanLing:更新了我的回覆 - 如果您只打算通過單個操作存儲和檢索整個XML blob - 沒有意義的是有很多小塊...... –

0

如果該字段將用於存儲應用程序有效負載,並且應用程序可以正確處理版本控制或未來對結構的修改,那麼我將使用xml字段。存儲爲xml的唯一缺點是查詢可能會耗費更多時間,而不是平滑數據。如果您的應用程序處理所有正在交給xml的數據,那麼這將成爲跳躍的一個較小障礙。

0

是的。

建議使用nvarchar(MAX)來存儲XML。因爲,如果(不久的將來)你打算修改你的存儲以保留json(而不是xml),那麼爲你保留Json將是非常靈活的。 但是,如果您選擇使用XML數據類型,則只能使用XML。然而,正如馬克提到的那樣,如果它真的看起來像XML,聞起來就像XML和庸醫般的XML--那麼肯定會使用XML數據類型! 如果您的業務用例說要一次性插入和檢索整個XML,那麼我並不認爲在將性能分解爲大塊方面有很多好處。

相關問題