归纳hibernate培训讲座.pptVIP

数据库设计的思考 这样的设计是不必要的，并且存在性能问题。 Entity and Component 在Java中不存在实体类和component类的区别，所有类的含义都是相同的。 持久化的类需要对应数据库的表，而表中记录的唯一性是通过主键实现的。故持久化的类需要区分实体类和component类。 Entity类有数据库的主键值， Entity类有自己的生命周期，它不依赖于其他的类而独立存在。 component类没有相应的主键值，它从属于Entity，它的生命周期从属于Entity，随着Entity的消亡而消亡。 component类也称value type。 映射文件的格式 Subtypes——子类型问题 对象模型存在“is a”和“has a”的关系，而关系模型仅仅存在“has a”的关系，这是对象模型和关系模型最明显的mismatch，如何将“is a”转化为数据库中的“has a”是hibernate需要解决的问题。 Table per concrete class 这是最简单的一种方式：每一个子类对应一张表，父类没有表。 这种方式会产生“Polymorphic queries”的问题。 Polymorphic queries—多态查询 对于父类的查询需要运行多条select语句，每个子类一条。select CREDIT_CARD_ID, OWNER, NUMBER, CREATED, TYPE, ...from CREDIT_CARDwhere CREATED = ?select BANK_ACCOUNT_ID, OWNER, NUMBER, CREATED, BANK_NAME, ...from BANK_ACCOUNT where CREATED = ? 父类的变动困难：父类的变动会影响所有的子类属性，从而会影响多个表中的字段。 仅仅用在不需要多态查询的场合。 Table per class hierarchy 整个继承树对应一张表，子类用type discriminator字段来区分。这种方式在性能和简单性两方面都做的很好。 父类的变动很方便。 多态查询 查询父类select BILLING_DETAILS_ID, BILLING_DETAILS_TYPE,OWNER, ..., CREDIT_CARD_TYPE, from BILLING_DETAILS where CREATED = ? 查询子类select BILLING_DETAILS_ID,CREDIT_CARD_TYPE,CREDIT_CARD_EXP_MONTH, ...from BILLING_DETAILS where BILLING_DETAILS_TYPE=CC and CREATED = ? problem：子类属性对应的column不可以有not null的约束。 映射文件的格式 Table per subclass 这种设计符合数据库的设计范式。 但是可能会有严重的性能问题。 多态查询的解决——父类 查询父类：用outer join 多态查询的解决——子类 查询子类：用inner join 这种方式如果用手工写代码完成则很困难。 查询需要关联多张表，对于复杂的继承树结构，性能是个大问题。 映射文件格式 继承策略选择 一般原则：如果你不需要多态查询，可以考虑用table-per-concrete-class，如果你需要多态查询，并且子类的属性差异不大，考虑用table-per-class-hierarchy，但是如果子类的属性差异很大，考虑用table-per-subclass。 经验：对于一般的解决，尽量用table-per-class-hierarchy， table-per-subclass请慎重使用。 associations—关联 对象之间通过reference和reference集合来关联，而关系模型则通过外键进行关联。 对象的reference是有方向性的，始终是单向的，如果需要双向的，则需要定义两次；外键则没有方向性，或者说天然就是双向的，因此导航对于关系模型没有意义。 对象模型存在多对多的关系，而关系模型只有one-to-many和one-to-one。如果关系模型要实现多对对，需要一个link table，而这个link table不存在于对象模型中。 many to one one to many 双向关联产生的问题 在内存中有两个不同的地方代表同一个值：即外键item_id 如果我们调用了bid.setItem(item);bids.add(bid); hibernate会认为是两个不同的持久类发生了变动，它并不知道这两个变动实际上是指向同一个数据库的字段，hibernate