国产精品第一视频,久久久999精品,欧美日韩视频在线第一区

[转]hibernate:one-to-one的学习小�l�验

Fri, 19 Aug 2005 05:45:00 GMT

one-to-one在hibernate中可以用来作��Z��张表之间的主键关联，�q�也是hibernate中主键关联的一�U�用法，�q�样在一张表中的ID�Q�在生成另外一张表的同时回自动插入到相应的ID字段中去�Q�相应的XML文�g讄��比较��单，举例如下�Q?BR>







     -->


      ��Z��在Address中��用User中的主键ID��|��我们需要设�|�Address中的主键生成规则�Q�如下所�C�，采用foreign关键�?BR>


        user



      �q�里需要注意的是property的属性值必��M��上面到User的映��所填写的name属性��g��?/EM>�Q�这样就完成了one-to-one的映��关�p�R�?BR>
上面的过�E�都很简单，下面我来说说�q�里需要注意的地方�Q?BR>
  1.   在设�|�属性ID的时候必��L��意字�D늚�长度�Q�如�W�者这样��用oracle的sequence来生成ID�Q�其长度�?4位之长，则应选择hibernate�c�d��long�Q�对应的实体中应选择Long�Q�这样不会出现溢出的情况�?/STRONG>

  2.   在测试的时候必��要注意�q�两张表之间因�ؓ已经存在了一对一的关�p�，所以我们不能只�?BR>         user.setAddress(address);
         而忽略了
         address.setUser(user);
         �q�样在做插入的时候会报出attempted to assign id from null one-to-one property: address的错误，�q�一点初学者会�l�常犯，�W�者也是其中之一�?BR>

3.   如果不写cascade="all"或者写成cascade="none"的话�Q�即使你写了
         user.setAddress(address);
         address.setUser(user);
       也不会发生�Q何事情，只有user会被存储�?BR>
以上是一些笔者经历的��经验，如果有不对的地方�Ƣ迎指正�?img src ="http://www.aygfsteel.com/jackybu/aggbug/10501.html" width = "1" height = "1" />

�?/a> 2005-08-19 13:45 发表评论

[转]One-to-one关系映射

Fri, 19 Aug 2005 05:30:00 GMT
对于hibernate�?/SPAN>one-to-one关系来说�Q�大家常常把它忽略，认�ؓ它很��单，其实�q�里面有些细节需要注意，�?/SPAN>hibernate3中有两种实现one-to-one的方法：�W�一�U�就是用many-to-one来代替一对多�Q�其�?/SPAN>one-to-one也就�?/SPAN>many-to-one的一�U�极限方式，若把many-to-one讄��unique="true"�Q�则�q�时候的many-to-one实质上就�?/SPAN>one-to-one;�q�里��Z��么能够用many-to-one来代�?/SPAN>one-to-one呢？最�Ҏ��的是两个对象必须有一个字�D늛�兌��Q�那么你也发�?/SPAN>one-to-one中没�?/SPAN>column属性，也就是不能够�?/SPAN>one-to-one的这�U�关�pȝ��成一个字�D?/SPAN>/属性，�?/SPAN>many-to-one可以�Q�它�?/SPAN>column属性。所以，说了�q�么多，你应该明白�ؓ什么可以用many-to-one来代�?/SPAN>one-to-one.

对于�q�种�Ҏ��要注意几点：

例如�Q�下面的介绍�?/SPAN>use中的两个字段同时影射adress�Q�只能够实现单向one-to-one,也就是从use�?/SPAN>adress�Q�不能够实现�?/SPAN>adress�?/SPAN>use.然但下面也介�l�了可以使用复杂的方法来解决�Q�但是得不偿失�?/SPAN>

�W�二�U�方法：��Z��主键兌��?/SPAN>one-to-one,�q�种�Ҏ��比较直接。也��是�?/SPAN>adress的主键值和use的一样就可以了，通过

user

来把adress的主键值和use的主键值相�{�。其余的讄��都是��事�?/SPAN>

对于初学者来说应该注意：单在use�?/SPAN>adress中设�|?/SPAN>one-to-one是不行的�Q�需要设�|�上面的代码�Q�需要实�?SPAN lang=EN-US style="FONT-SIZE: 14pt; mso-font-kerning: 0pt">one-to-one两端的对象主键值相同，�q�是最主要�?/SPAN>。这也是one-to-one�?/SPAN>many-to-one的不同之处。应当注意�?/SPAN>

                                                                                           fasttalk

                                                                              www.aygfsteel.com/asktalk

Using a foreign key association

The easiest way to represent the association from User to its billingAddress is to use a mapping with a unique constraint on the foreign key. This may surprise you, since many doesn’t seem to be a good description of either end of a one-to-one association! However, from Hibernate’s point of view, there isn’t much difference between the two kinds of foreign key associations. So, we add a foreign key column named BILLING_ADDRESS_ID to the USER table and map it as follows:

class="Address"

column="BILLING_ADDRESS_ID"

cascade="save-update"/>

Note that we’ve chosen save-update as the cascade style. This means the Address will become persistent when we create an association from a persistent User. Probably, cascade="all" makes sense for this association, since deletion of the User should result in deletion of the Address. (Remember that Address now has its own entity lifecycle.)

Our database schema still allows duplicate values in the BILLING_ADDRESS_ID column of the USER table, so two users could have a reference to the same address. To make this association truly one-to-one, we add unique="true" to the element, constraining the relational model so that there can be only one user per address:

class="Address"

column="BILLING_ADDRESS_ID"

cascade="all"

unique="true"/>

This change adds a unique constraint to the BILLING_ADDRESS_ID column in the DDL generated by Hibernate—resulting in the table structure illustrated by figure 6.7.

But what if we want this association to be navigable from Address to User in Java? From chapter 3, you know how to turn it into a bidirectional one-to-many collection—but we’ve decided that each Address has just one User, so this can’t be the right solution. We don’t want a collection of users in the Address class. Instead, we add a property named user (of type User) to the Address class, and map it like so in the mapping of Address:

class="User"

property-ref="billingAddress"/>

This mapping tells Hibernate that the user association in Address is the reverse direction of the billingAddress association in User.

In code, we create the association between the two objects as follows:

Address address = new Address();

address.setStreet("646 Toorak Rd");

address.setCity("Toorak");

address.setZipcode("3000");

Transaction tx = session.beginTransaction();

User user = (User) session.get(User.class, userId);

address.setUser(user);

user.setBillingAddress(address);

tx.commit();

To finish the mapping, we have to map the homeAddress property of User. This is easy enough: we add another element to the User metadata, mapping a new foreign key column, HOME_ADDRESS_ID:

class="Address"

column="HOME_ADDRESS_ID"

cascade="save-update"

unique="true"/>

The USER table now defines two foreign keys referencing the primary key of the ADDRESS table: HOME_ADDRESS_ID and BILLING_ADDRESS_ID.

Unfortunately, we can’t make both the billingAddress and homeAddress associations bidirectional, since we don’t know if a particular address is a billing address or a home address. (We can’t decide which property name—billingAddress or homeAddress—to use for the property-ref attribute in the mapping of the user property.) We could try making Address an abstract class with subclasses HomeAddress and BillingAddress and mapping the associations to the subclasses. This approach would work, but it’s complex and probably not sensible in this case. Our advice is to avoid defining more than one one-to-one association between any two classes. If you must, leave the associations unidirectional. If you don’t have more than one—if there really is exactly one instance of Address per User—there is an alternative approach to the one we’ve just shown. Instead of defining a foreign key column in the USER table, you can use a primary key association.

Using a primary key association

Two tables related by a primary key association share the same primary key values. The primary key of one table is also a foreign key of the other. The main difficulty with this approach is ensuring that associated instances are assigned the same primary key value when the objects are saved. Before we try to solve this problem, let’s see how we would map the primary key association.

For a primary key association, both ends of the association are mapped using the declaration. This also means that we can no longer map both the billing and home address, only one property. Each row in the USER table has a corresponding row in the ADDRESS table. Two addresses would require an additional table, and this mapping style therefore wouldn’t be adequate. Let’s call this single address property address and map it with the User:

class="Address"

cascade="save-update"/>

Next, here’s the user of Address:

class="User"

constrained="true"/>

The most interesting thing here is the use of constrained="true". It tells Hibernate that there is a foreign key constraint on the primary key of ADDRESS that refers to the primary key of USER.

Now we must ensure that newly saved instances of Address are assigned the same identifier value as their User. We use a special Hibernate identifier-generation strategy called foreign:

user

...

class="User"

constrained="true"/>

The named property of the foreign generator allows us to name a one-toone association of the Address class—in this case, the user association. The foreign generator inspects the associated object (the User) and uses its identifier as the identifier of the new Address. Look at the table structure in figure 6.8. The code to create the object association is unchanged for a primary key association; it’s the same code we used earlier for the many-to-one mapping style.

�?/a> 2005-08-19 13:30 发表评论

[转]one-to-one的效率问题，用one-to-many来替代？

Fri, 19 Aug 2005 05:26:00 GMT
�׃��最�q�在把以前的一个设计移到hibernate上来�Q�所以需要用到one-to-one�Q�因为在以前的设计中需要用到在一个主表中对于多个子表的主键关联，所以一开始就惛_��了one-to-one的应用，觉得�q�样解决不但不会引�v以前数据设计的改变，也能够很好的利用hibernate所带来的OR优势�Q�可是当实际使用的时候发玎ͼ�在插入数据的时候可以有选择的在��L��子表中进行插入，所有的�l�果都在原来的预期之中，但是在查询的时候，比如说只查询主表中的内容

         From tableMain

仅仅执行看�v来十分简单的一条语句，你所期望的是他紧紧查询T_MAIN�q�张主表�Q�可是结果确实hibernate通过多个外连接将所有的子表一口气的全部查询出�?BR>
         select * from t_main main outer join t_sub1 sub1 on main.id = sub1.id outer join t_sub2 sub2 on main.id = sub2.id...

如此的效率绝对让你头痛不�Ԍ��不仅如此�Q�如果你通过首先获得子表t_sub1的某个主键ID�Q�然后通过�q�个主键查询出子表对象，在关联至住表�Q�同��L��情况又会发生�Q�又会生成类似的SQL语句�Q�这样一来看来对于这个设计应用one-to-one本��n��是一�U�错误，是这样吗�Q?BR>
         或许有�h认�ؓ我们在每个one-to-one中加入lazy="true"�q�个属性会杜绝上述情况的发生，�l�过�W�者的证实即便你加入了lazy="true"�Q�也不会带来��M��的改变；又或者在hibernate.config中加入fetch depth属性以及在每个兌��中设�|�outer-join="false"�Q�这些都不会引�v本质上的变化�Q�加入outer-join="false"其实�l�果只是��原有的outer join语句改变成多条sql语句而已�Q��ƈ没发生什么本质变化，反而效率更低了�?BR>
         该怎么办呢�Q�我们先仔细研究一下one-to-one的概念，one to one代表一对一�Q�在一般的模型中很��会遇到one-to-one�q�种概念�Q�因��Z��十分��一对一的概念，��好比一个�h他只有一个��n体和一个头而已�Q�头和��n体是十分好的例子�Q�因为有�w�体必定只有一个头�Q�而且说到了��n体必定要说头�Q�就好像看了某个奛_��的��n材必定想知道她的长相如何�Q?_-�Q�，所以在�q�时我们使用one-to-one�Q�因��U�一对一的关�p�L��很强的，而且从对象中取得body必定会取得他所兌��的head�Q�这��L��情况下��用outer-join是十分方便和有效率的�Q�因为它使用了outer join查询从而避免了两条到数据库的查询语句，而且在这�U�情况下也只需要在body_hbm.xml中设�|�一个one-to-one卛_��Q�所以在�q�种��实是一对一而且在主表中一对一的关联个敎ͼ�即主表中one-to-one标签�Q�十分少的情况下�Q��用one-to-one是一�U�很不错的解军_��法�?BR>
         如果一个主表会对多个子表都�q�行one-to-one兌��呢，��像我们一开始遇到的�q�种情况�Q�比如你不仅仅只想了解那个你中意的女孩的�w�材和脸蛋，而且�q�想知道他的学历�Q��n世等�{�一切，在这�U�情况下�Q�如果我们都是用多个one-to-one在主表中的话�Q�那情况正如我们一开始看见的�Q�是十分可怕的�Q�该怎么做呢�Q�不妨考虑一下��用one-to-many�Q�什么，many?一开始听到many�q�个词的时候，我也觉得挺惊讶的�q�明明是多个一对一的关联�ؓ什么要用到many呢？其实many�q�没有一定要说是大于一的，你就只在它的many中存在一个关联它有能乃你何呢�Q�如果用到many的话�Q�我们就需要改动数据表的设计了�Q�在每个有关�q�的子表中加入一列main_id代表主表中该记录的主键子�D��|��只需要这样子改动��可以了�Q�这��h��带来的效果绝�Ҏ��值得你这样做的，然后我们��按照以往的one-to-many来设计就好了

         在body.hbm.xml加入�Q�一到head的关联�D例，其他的关联按照这��L��格式��d��卛_��Q?BR>




         在head.hbm.xml加入


         行了�Q�经�q�上面的改动我们��摆�׃��查询时多个outer-join的困扎ͼ�只在需要的时候才对子表进行查询，因�ؓ讄��了lazy="true"�Q�所以一切的一切都在我们的预料之中�Q�我们如果希望获得body的话hibernate�l�对不会把它的head 也查询出来，节省了查询是所需要的负担�Q�除非到了我们十分需要head的情冉|��会进行关联查询，获得所需要的head�l�果�?BR>
         所以由此看�?FONT color=#0000ff>在one-to-one�q�种一对一的关�p�M��是很强的情况下，或者是在一张表中存在多个one-to-one的情况下�Q��用one-to-many来代替one-to-one不失��Z��U�不错的做法�Q�当然更重要的良好的数据库设计，hibernate毕竟只是末，千万不要本末倒置�?BR>

�?/a> 2005-08-19 13:26 发表评论

Tue, 09 Aug 2005 13:21:00 GMT
Q:Hibernate的检索方式有很多
对象囄��D��索，load/get��索，HQL(find,Query)��索，QBC(Criteria�Q�QBE)��索以及本地数据库SQL��?
那么�Q�在实际应用中到底选择哪一�U�检索好�Q�它们之间的��索有哪些联系和区别呢�Q?/SPAN>

A:(by Robbin)HQL功能最强大�Q�适合各种情况�Q�但是动态条件查询构造�v来很不方�?
Criteria最适合动态条件查询，不太适合�l�计查询�Q�QBE�q�不够强大，只适合相当��单的查询
NativeSQL可以实现特定数据库的SQL�Q�但是可�U�L��性就牺牲�?

Hibernate2的Criteria功能不够完善�Q�所以Hibernate2上面可用的只有HQL和NativeSQL�Q�Hibernate3的Criteria已经非常强大了�?

我的选择原则是：

针对web应用来说�Q�大部分常规查询都是动态条件查询，所以首选��用Criteria�Q��ƈ且Hibernate3提供了DetachedCriteria�Q�可以在web层构造好DetachedCriteria再进入session执行查询�Q�非常方便实用的�Ҏ��?

但是涉及到统计查询和非常复杂的关联查询，Criteria��无能�ؓ力了�Q�这�U�情况下我选择使用HQL�?

最后如果必��M��用某些数据库的特性，例如Oracle�?...connect with ... by"�q�样的SQL�Q�则选择使用NativeSQL�?/SPAN>

�?/a> 2005-08-09 21:21 发表评论