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

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

...繼續閱讀 »

[Data Access] ORM 原理 (10) : 全程式碼對映–當 ORM 遇到 Lambda 與 Fluent Interface

ORM 原理前面8集中己經講述了基本的ORM核心內的運作方式,大多數的ORM其實都是這麼做,當然還會做一些更進一步的最佳化工作,例如產生SQL的方式等。不過既然都是寫程式的,當然會希望這些對應欄位的設定工作可以完全的程式化 (Coded Map),而不用再假手那麼多的設定檔。

...繼續閱讀 »

[SQL Server] 鎖定使用的藝術 (Part 1) - 鎖定控制類型

只要是寫到資料庫存取程式,而且程式又是多人運作 (這裡的多人是指 100 個人以上同時存取) 的環境時,很難不碰到並行處理 (Concurrency Process) 的問題,並行處理在資料庫系統中是一門很重要的學問,因為它一定會出現在商業運轉的環境,而且問題不只是資料庫,像是執行緒的處理也會遇到這樣的問題,所以在並行環境下資料庫都會有一些行動或處理方式,鎖定 (Lock) 就是其中一種。

...繼續閱讀 »

[SQL Server] 游標使用的藝術

在資料庫的設計中,用戶端程式的存取通常會扮演重要的角色,因為用戶端的數量,使用的存取方式,SQL 指令,交易處理等都會影響到資料庫應用程式的效能。我們一般在想定資料庫發生效能問題時,最有可能的幾個因素是 CPU/Memory 以及 I/O 能力,對應到用戶端的程式處理的話,通常就是 SQL 指令,連線開關以及資料的存取方式,這三種通常會具有資料庫效能的決定力。

...繼續閱讀 »

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

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

...繼續閱讀 »