※ 引述《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