HIBERNATE/JPA successful use of 10 points of experience

About a year ago, I was involved in a hibernate project to learn some hibernate expertise. Since then, I've been using the JPA (Java Persistence API) under the Hibernate framework, and the idea is still the same. The project uses a database that is somewhat large, slightly backward, and is shared by many applications. In order to join the project as soon as possible, I began to learn some hibernate knowledge. Learning from the examples in the book, it feels simple and quick to learn, but it is another matter to discover that a project has been developed from scratch and controlled. Trying to use hibernate on a large, complex database that is shared by many applications is completely different. Figuring out the technical difficulties I may have encountered, I began to think of other ways, to start from another direction as soon as possible to overcome difficulties.

In the final study and practice, I found that I still learned a lot of important things, although our project has not been fully completed, but I think we have been very beautiful application of HIBERNATE/JPA some of the ideas. Now I need to rethink what I've learned, and here are some of the things I've learned:

1 and database administrator to become friends

There is a trend that some Java developers ignore the importance of database administrators. This makes a big mistake, and it is vital that you maintain a good working relationship with your database administrator to get any ORM (Object Relational mapping) technology successful. There are two reasons for this:

Individual database administrators may not be able to make hibernate projects successful, but they can often fail these projects.

Database administrators have a good insight into the database itself, good professional habits, tell you some of the mistakes and operational recommendations. I can remember many examples of this, a database administrator's proposal saves us a lot of time and provides us with a good solution.

In most cases, having a good database administrator and having a good relationship with them is critical to your ORM (Object relational mapping) work.

2 use (preferably mandatory) good naming standards from the outset

We know that the discussion of naming standards will be controversial, but we have to be clear about one thing, and our naming makes sense for our data model, which makes it easy for developers to use, lest they get confused. Therefore, it is important to name the entities and attributes. I have the criteria I like to name and think they are the best, but I don't want to impose them on you here. The most important thing is that you make your own decisions about what naming standards to use and let everyone use it. In fact, not only does the naming standard need to be unified, but other needs (e.g., Boolean with "y/n" or 0/1 representation).

3 Don't try to map all the properties

We always try to use tools such as Dali to map everything, and then form a table (some tables have hundreds of columns!). ）。 It's going to be a lot of trouble eventually. Why? Because we are using a shared, previous database, there are many fields that we don't care about and never use. Mapping them can only cause performance problems and create confusion.

4 Let the database do their own good work

We want to have a good, clear data model, so we do whatever it takes to write some additional query statements to get object-related data, either using stored procedures or using functions. This is the wrong approach, and the database advantage is in storing, rather than keeping hibernate data created or read-write. For example, we have an object that is associated with a state. This state is used throughout the application, so there is no doubt that it will be done, but we don't want to write a single query every time. The problem is that this state is derived from some statistical calculations, and these statistics require a one-to-many relationship. The cost of reading data from loaded objects is very high at each time. Then we talked to one of our database administrators and found that a SQL function we could use would quickly get to that state. We use @formula to map a state attribute to get everything we need. This is still part of the domain model, but it's very good to perform. Sometimes a compromise like this can have a great effect.