→ bala045:阿 第一本看過了 寫得很詳細 很複雜 06/27 11:56
※ 引述《kidd0730 (大阪掛川大不同)》之銘言：
: google OR mapping後,對他的認知僅在於可以把撈出來資料暫存,
: 然後可以像是直接對table操作一樣 用row和column去操作table
: 那和我用rs.get後先放在Hashtable,再用Hashtable.get()的方式取得value再操作
: 以結果來看 2者都可以達到相同效果
: 那請問這2者有何差異呢?
: 是效能上還是底層的運作不一樣呢
: 不都是先把table的資料先暫存起來嗎
要知道 Object-Relation Mapping 這個對應「工具」的來由，
需先思考物件導向語言描述一個世界的方法與關聯式資料庫的異同。
對物件導向語言來說，
它利用類別作為樣版來描述一個實體(instance)應有的欄位(field)與行為(method)。
對關聯式資料庫設計者來說，
透過觀察並抽象化資料，歸納需獨立存在的實體(entity)與相關屬性(attribute)
就這概略的描述來看，關聯與一個單純的類別(沒有繼承、沒有合成關係)差異並不顯著。
就這個層次來說，它們在設計上遭遇的共通問題 -- granularity 粒度，
如何找出一個最適當的大小，用它來構成一個類別(class)或實體(entity)，
以至能合理地對應至真實世界，並用它來描述、處理我們的問題。
這問題可以留著設計著去煩惱，但物件導向語言擁有更多的語意，
這多出來的部分，正是您想瞭解的差異所在。
就以物件之間的關係來說，要如何在關聯式資料庫模擬出下列的情況呢？
* 關聯 (association)
* 合成 (composition)
* 繼承與多形
* 群集 (collections)
關聯與合成在結構上相同，但在語意上就不同了。雖然都是一個類別內，再包一個類別：
class Order {
Customer customer;
}
class Customer {
Address address;
}
但對 Order 與 Customer 的關係來說，訂單取消了(如果要刪除的話)，
客戶並不需要被刪除。
再看看 Customer 與 Address 的關係，如果客戶被刪除了，獨留地址是沒有意義的。
這語意上的問題，是 ORM 在設計時的一大挑戰。
(如果有 DB 達人就不要戰我了 :P
在實務上他們會強烈建立您設計為用「停用」來取代「刪除」 )
然而，問題並不會只由物件導向體多出來的語意產生，另一個觀察的角度。
如何用物件體系描述一對一、多對一、一對多、多對多、弱個體等關係，
也是 ORM 設計時的挑戰。
若要提一些比較與 ORM 使用者相關的問題，那您必需注意的是：
*「物件相等性」與「關聯表主鍵」對應的問題。
(Java 的 equals, hashCode 該怎麼對應至 PK 判定相等性)
* 效能調整問題 (ex. 資料庫查詢 n+1)
* 交易問題 (Long Conversation、並行層級)
* 不同資料庫支援資料型別的問題 (Hibernate 用 Dialect 設計克服)
* 即使有抽象化的查詢方式(ex. Hibernate Query Language)，
也要知道哪些寫法會在資料庫轉移時會需要修改。
其實，使用 ORM 看似簡單，但要做到玩弄的它境界。
還需要徹底理解資料庫與 ORM 本身提供的能力。
撰寫 SQL 的複繁看似被隱藏了，
但得真誠的理解 ORM 帶來的新問題，才能與它和平共處。
=====================================================================
以上是超濃縮版讀書心得，若想更深入瞭解 ORM，
可以參考 Hibernate 開發者 Gavin King 所著的書：
Java Persistence with Hibernate
Second Edition of Hibernate in Action
Christian Bauer and Gavin King
http://www.manning.com/bauer2/
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 61.231.53.241