[.NET][Database] 資料庫中的 NULL 值

在資料表結構 (table schema) 中,每個欄位除了基本的欄位名稱、型態、大小等資料外,有一個有趣的欄位很特別,就是是否允許 NULL,NULL 這個東西對程式設計師來說是又愛又恨,有時會被它搞得嫑嫑的,但是它有時卻又是一個有必要的存在。

...繼續閱讀 »

[Data Access] ORM 原理 (11): 效能議題

這絕對是 ORM 的使用者,開發人員與 DBAs 共同想要問的議題,到底我使用了 ORM 和使用傳統的 ADO.NET 下 SQL 指令的方式會差多少? 這個問題不但會發生在 Entity Framework 上,也會發生在 NHibernate 等 ORM Framework 內,連同我自己在這個系列文中開發的 ORM 機制也會受到影響...

...繼續閱讀 »

[Data Access] ORM 原理 (7) 物件關聯性

資料關聯 (data relation) 是 DBMS 的特色之一,它通常也是和物件難以整合的重要因素,因為物件的關聯和資料的關聯是不同的,物件的關聯是在物件內以屬性的方式連接另一個物件,但資料的關聯是在兩個表格之間以鍵值資料 (key) 串接,且 SQL 指令會透過 JOIN 指令 (不論是 INNER, OUTER 或 FULL) 來撈取關聯的資料,只是如果要在 ORM 內實作這樣的機制,勢必會有不小的難度,因為 JOIN 指令要由 ORM Framework 來產生,而且在取得關聯資料時,ORM Framework 未必會直接撈取關聯資料,而是在存取行為發生時才會實際填入資料 (又稱為延遲載入),後者要判斷的事就更多了。

...繼續閱讀 »

[Data Access] ORM 原理 (6) : 單純化資料存取程式

ORM 原理走到第六步,核心只會愈來愈複雜,但用戶端相對會變得簡單,會寫這一系列文的用意,是告訴大家 ORM 的核心大概的作法,像 NHibernate 或 Entity Framework,核心做法其實差不多,當然這些著名的 ORM Framework 一定沒那麼簡單,還有很多的配套功能要做,只是我想告訴大家的是,ORM 本身不會因為它看起來像物件就可當沒有 SQL 這回事,當物件存取和關聯愈來愈複雜的時候,Object 和 SQL 之間的互動複雜度就會成等比級數一樣。

...繼續閱讀 »

[Data Access] ORM 原理 (5) : 欄位對應的進階考量

在原理 (4) 中,我們使用了特徵項 (attribute) 來處理欄位對應的問題,只是這個方法對於可能時常異動欄位名稱,或是想要利用 copy/paste 以及擴大使用範圍的需求來說,可能就沒那麼恰當,因為使用特徵項最大的缺點就是:它是寫死 (hard-code) 的,若是想要修改欄位名稱的話,勢必又要重新 compile...

...繼續閱讀 »

[Data Access] ORM 原理 (3) : 處理列舉型別 (Enumeration Type)

我們在原理 (2) 中處理了許多內建的型別,不過還有幾種比較棘手的型別,其中一個就是列舉 (enumeration),列舉也是一種實值型別,只是它大多用來作為限制常數的用途 (使用有意義的指令取代數字),而且它不能用在泛型,所以 where 等於是不能用 (雖然有替代方案)。

...繼續閱讀 »

[Data Access] ORM 原理 (2) : 處理不同型別

我們首先了解了 ORM 的繫結物件屬性與欄位時使用的方式,只是還有個問題,就是我們原先用的屬性型別都是 string,很好處理沒錯,但大多數的資料結構沒這麼簡單,一定不會只有 string 型別,像 int, double, long, char, boolean 這些型別也時常出現,那麼要怎麼處理這些型別間的轉換?

...繼續閱讀 »

讓資料保持彈性的設計:Profile 架構

如果可以由資料庫本身去做彈性設計的話,對於物件使用 ORM 以及擴充上會有正面幫助,物件可以不受物件既有資料表欄位的限制,即可由物件自己去決定會多或會少哪些資料,而資料庫依照物件的要求做出反應,即可確保物件的高彈性,又可以簡化資料表的設計。這個方法即為 Profile 架構。

...繼續閱讀 »