網域查詢: www.
返回首頁
當前位置: 首頁 > 站長學院 > 數據庫 > MSSQL >

CLR自定義類型存儲對象

時間:2010-02-17 17:17來源: 作者: 點擊:
問︰我可以在SQL Server 2005中用CLR用戶自定義類型來存儲我的業務對象嗎? 答︰實現SQL CLR用戶自定義類型(UDT)非常簡單,就像給.NET類或者結構添加一些額外的片斷。其中就包括屬性(SqlUse
  

問︰我可以在SQL Server 2005中用CLR用戶自定義類型來存儲我的業務對象嗎?

  答︰實現SQL CLR用戶自定義類型(UDT)非常簡單,就像給.NET類或者結構添加一些額外的片斷。其中就包括屬性(SqlUserDefinedTypeAttribute),和接口(INullable),以及一些額外的方法(Null() and Parse())。這個簡單性帶來的後果就是,一個有經驗的開發人員可以在不到5分鐘的時間里把一個業務對象轉換為SQL CLR 用戶自定義類型。

  SQL Server 2005的設計目標並不是用于面向對象的數據庫管理系統。它還是一個標準的SQL 數據庫管理系統,並且用戶自定義類型的能力也應該被當作是一種系統擴展的類型,而不是一個對象。開發人員在決定是否將現有的業務對象用作CLR UDT的時候,應該仔細權衡他們的選擇。

  每次訪問一個類型的實例的方法或者屬性的時候,這個實例都應該在這個方法被訪問之前串行化。因此,這最好是依靠那些基于他們的串行化字節的可比較的類型。開發人員應該嘗試僅僅使用那些可以自動回答問題的用戶自定義類型。例如,以下的C#類就不如用戶自定義類型:

class Product
{
   public string Name;
   public string Description;
   public decimal price;
}

  如果一個查詢是針對這樣類型的字段,每個行都必須被反串行化以回答如下的問題,“什麼產品價值10美元?”這是因為我們不能假設所有的10美元的產品都具有同樣的二進制表示。對一個大表(例如一個有上百萬產品的表)中的每個行都進行反串行化將會給性能帶來嚴重的考驗。

  除了性能挑戰之外,還有標準化的問題。例如,假設這個類型,一個公司怎麼能為同樣的產品存儲兩種描述,並且還要確保產品只有一個有效的價格?

  最好是堅持使用那些可以回答問題,並且不會帶來反串行化負擔的類型。


頂一下
(0)
0%
踩一下
(0)
0%
------分隔線----------------------------
最新評論 查看所有評論
發表評論 查看所有評論
請自覺遵守互聯網相關的政策法規,嚴禁發佈色情、暴力、反動的言論。
評價:
表情:
用戶名: 密碼: 驗證碼:
推薦內容