Description of Hibernate relationship mapping

The open source Framework's mapping of the data layer includes the mapping of entities and the mapping of relationships, where the mapping of relationships is the most complex. 　　If you have a bad relationship mapping, you simply don't use it, otherwise it can seriously affect performance. <?xml:namespace prefix = o ns = "Urn:schemas-microsoft-com:office:office"/>

There are four entity relationships in Hibernate, basically the same entity relationships we learned in database modeling, namely one-to-many relationships, a-to-multiple relationship, a many-to-a relationship, and many-to-many relationships. We give the following descriptions separately:

One or one to one relationship, many-to-one relationship

One-to-one, multi-pair relationship The code embodiment is the inclusion of an entity class attribute in JavaBean. For example, the relationship between a husband and wife is a one-to-another, then there should be a property in the husbands attribute is the spouse, the wife attribute should also have a property is the husband. Similarly, in a many-to-one relationship, the code embodiment also contains an entity class attribute in Java. For example, the relationship between a child and a mother is a multi-to-one relationship, and every child should have a property that is mother. We found that, whether one-to-one or many-to-a, they are all the same in code, that is, the attribute contains an entity class attribute. In fact, a one-to-one relationship is a special case of many pairs of relationships. Therefore, when mapping, a one-to-one relationship or a many-to-a relationship that is implemented by a foreign key, either way, the relationship property of the foreign key's side is mapped by Many-to-one, not by one-to-one.

Two or one-to-many relationships, many-to-many relationships

These two relationships also have some commonality, that is, their code is reflected in the JavaBean contains a collection of properties. For example, in the above-mentioned relationship between the mother and the child, the mother should contain a collective attribute, which contains all of her children in this collection. This one-to-many relationship uses One-to-many to map, in the database is reflected in a party that does not contain foreign keys. Many-to-many relationships, though, also include a collection property in the attribute, but the many-to-many is used when mapping. This is mainly because many-to-many relationships require a relational table and must tell hibernate who the relational table is.

The above is simply a summary of some of the characteristics of hibernate in the relationship mapping, the following is the problem of hibernate relationship mapping in the difficulties.

If you're not really using hibernate to develop projects, it's hard to understand why it's best not to use relationships if you have a bad relationship. Here are a few questions:

1. Cascade operational issues for the relationship.

We know that in the database, the establishment of foreign keys while establishing a constraint relationship. There is a problem with what the current row should do when the row that the foreign key points to the table is deleted. For example, the husband table contains a foreign key pointing to the wife, and if the wife is deleted, then the value of the foreign key of the husband's row should be manipulated. If the original value remains the same, but the wife he points to is no longer there, there is no point in such a record, so there must be some action. In the database will generally be based on the user's settings to take three kinds of behavior, one is to give a hint, tell you because there is a foreign key point to this line, so can not be deleted, if you want to delete, you must first point to its foreign key but the second is to delete the current row, the foreign key points to the empty; All the rows that point to it are also deleted.

The general database takes the first behavior by default, so that if you do not make any settings, when we delete an entity, an error will be made, telling you that there is a foreign key pointing cannot be deleted.

How to solve this problem. You can do a database design beforehand and let the database help you take a more appropriate action. Two optional deterministic behaviors, that is, empty or cascading deletes. Which is more appropriate to use, depending on your application, confined to space, I do not do too much explanation here. In addition, Hibernate's Cascade property can be used, and its delete represents an empty foreign key when it is deleted, while Delete-orphan deletes the row that points to it when it is deleted.

2. The direction of the relationship

"A slap does not ring", a relationship must have two entities. There is another problem, when an entity changes, whether the relationship must also change. This problem is difficult to tell because it is associated with a specific application. Sometimes we just update the entity and don't want to update the relationship, and sometimes we want to update the relationship without updating the entity, and in some cases we are both entities and relationships to be updated at the same time. By default, Hibernate is updated for both entities and relationships, even if you have not changed the relationship at all. This has a greater impact on performance. We can set a inverse property to the relationship and tell it not to update the relationship under any changes. Of course there are other ways in which readers can refer to their documentation. In short, this is a very complex problem that depends on your application.

3, n+1 query questions

about what is n+1 query, I do not want to explain, the reader can look at my previous article or to the Internet to inquire. In general, the problem with n+1 queries is that performance is too low and in some cases can even cause the system to crash. But sometimes it's good. Because the n+1 query is actually deferred loading, it saves space. Hibernate has a fetch property that describes the strategy for fetching data, and if you choose Join, you won't use the n+1 query, but loading up all the data is not necessarily what you want, it can also waste storage space.

4. Delayed loading

Lazy loading is not the time to load the data when it is read, but to wait until it is loaded. So how does hibernate know when users are using the data? How to load the data again. In fact, it is very simple, it uses the proxy mechanism. It is not the entity itself that is returned to the user, but the proxy for the entity object. The proxy object will go to the database to load the data when the user invokes the Getter method. However, loading the data requires a database connection. And when we close the session, the database connection is closed at the same time. This is called an uninitialized relationship.

The advantage of lazy loading is that it saves storage space. Because we don't need relational data in all cases. For example, mother and child. If you just want to change your mom's data, and hibernate will load 10 of her children at the same time, it's obviously pointless. So you can use the Hibernate.initialize () method to proactively decide whether to initialize a relationship. Of course, the lazy attribute can be passed in the configuration file, but it is fixed, either delayed or not delayed.

There are a lot of questions about Hibernate's relationship, which is confined to the space. Or the beginning of the sentence, if you do not have a good understanding of the relationship in hibernate mapping, then you simply do not use, or seriously affect performance.