小朱® 的技術隨手寫

本部落格不吹捧、不自戀、不造神，也絕不用技術文偷渡政治文，請各位朋友安心服用。

2017-05-20

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

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

...繼續閱讀 »
2012-08-23

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

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

...繼續閱讀 »
2011-11-24

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

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

...繼續閱讀 »
2011-11-24

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

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

...繼續閱讀 »
2011-11-17

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

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

...繼續閱讀 »
2011-11-10

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

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

...繼續閱讀 »
2011-11-10

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

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

...繼續閱讀 »
2009-07-16

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

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

...繼續閱讀 »

標籤雲