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