Comparison of advantages and disadvantages of JDBC and Hibernate

1. Hibernate is a lightweight JDBC object encapsulation. It is an independent object persistence layer framework and has no necessary connection with app server and EJB. Hibernate can be used in any situations where JDBC can be used, such as the database access code of Java applications, the implementation class of Dao interfaces, and even the code for accessing the database in BMP. In this sense, Hibernate and EB are neither a category nor a relationship between them. 2. Hibernate is a framework closely related to JDBC, so the compatibility of Hibernate and the JDBC driver have a certain relationship with the database, but it is related to the Java program that uses it, it has nothing to do with the app server, and there is no compatibility problem. 3. hibernate cannot be used directly to compare with Entity Bean. It can be compared only in the framework of the entire J2EE project. In addition, even in the overall framework of the software, Hibernate emerged as a replacement for JDBC, rather than an alternative to Entity Bean. Let me repeat the framework structure that I have already listed n times: traditional Architecture:

1) Session Bean <-> Entity Bean <-> DB

Alternative architecture to solve performance barriers:

2) Session Bean <-> Dao <-> jdbc <-> DB

Use hibernate to improve the development efficiency of the above architecture:

3) Session Bean <-> Dao <-> hibernate <-> DB
Analyze the above three architectures: 1. memory consumption: The JDBC architecture 2 is undoubtedly the most memory-saving, the hibernate architecture 3 is the second, and EB architecture 1 is the worst. 2. Operational Efficiency: If JDBC code writing is very optimized, the JDBC architecture runs most efficiently, but in actual projects, this is almost impossible. This requires programmers to be very proficient in JDBC, adjust the batch size and fetch size parameters of the preapredstatement using batch statements, and use the result set cache when necessary. In general, programmers cannot do this. Therefore, the hibernate architecture shows the fastest running efficiency. EB's architecture efficiency will be very poor. 3. Development efficiency: with the support of JBuilder and simple projects, EB architecture has the highest development efficiency, followed by JDBC, and hibernate has the worst. However, in large projects, especially when the persistent layer relationship ing is complex, Hibernate is highly efficient, followed by JDBC, and EB architecture is likely to fail. 4. distributed, security check, cluster, and Server Load balancer support. Because there are Sb as facade, there is no difference between the three architectures. 4. Where are the learning difficulties of EB and hibernate? Where is EB difficult? Rather than complex xml configuration files, EB may suffer from severe performance barriers due to a slight carelessness. Therefore, it is difficult for you to learn a lot of EJB Design Patterns to avoid performance problems. You need to learn the configuration of APP server and EB to optimize the running efficiency of EB. For EB development, most of the programmer's energy has been put on EB's performance problems, instead, you can focus more on the design of the Object persistence layer. What is the difficulty of hibernate? Not the complexity of hibernate itself. In fact, Hibernate is very simple, and it is difficult to be too flexible in hibernate. When you use EB to implement the persistent layer, you will find that eb is too clumsy, so you have no choice at all, therefore, you don't have to spend any energy designing a solution, balancing the advantages and disadvantages of the solution, and worrying about which solution to choose, because only the only solution is in front of you. You can only do this, no choice. On the contrary, Hibernate is too flexible. You can set at least
I have come up with more than a dozen solutions to solve the problem. So I am very hard to solve it. Is it still useful to use it? What are the differences between these solutions? What are their operating principles? Which one is more efficient? If you generate a primary key, there are seven or eight solutions for you to choose from? Set, list, and bag can be used for set attributes. Which efficiency is high? Iterator can be used for queries, list can be used, which is better, what is the difference? Are you embarrassed? You can configure the composite primary key directly in HBM or customize the customertype. Which one is better? Are you embarrassed? For a table, you can select a single ing object, or map it to a parent-child object. You can also map it to two objects. Under what conditions can you use to compare them?
Okay, are you embarrassed? This list can be listed until you don't want to see it again. When there are countless dazzling solutions in front of you, will you feel happy? Or sad? If you are a responsible programmer, you will certainly carefully study the differences between each solution, the efficiency of each solution, and the application scenarios of each solution, you will feel that you are already in and cannot be pulled out. If you use EB, you have made a decision in the first second, and you have no choice at all. For example, you can only use collection for set attributes. If it is hibernate, you will be in the bag, there is no way to write a list or set. Supplement:

Compared with hibernate in terms of performance, JDBC has advantages in flexibility. However, Hibernate has some advantages in learning and usability. JDBC is advantageous when many complex multi-table joint queries and complex database operations are used.

Similarities:

◆ Both are Java database operation middleware.

◆ Neither of the two objects that perform direct database operations is thread-safe and must be closed in a timely manner.

◆ Both can perform explicit transaction processing for database update operations.

Differences:

◆ Different SQL languages: JDBC uses the standard SQL language based on relational databases, and hibernate uses the hql (Hibernate query language) language.

◆ Different operation objects: JDBC operates on data and transfers data directly to the database through SQL statements. hibernate operates on persistent objects, the data of the underlying persistent object is updated to the database.

◆ Data status is different: the data operated by JDBC is "instantaneous", the value of the variable cannot be consistent with the value in the database, and the data operated by Hibernate is persistent, that is, the Data Attribute Value of the Persistent object can be consistent with the value in the database.

JDBC and hibernate read performance

1. JDBC is still the fastest access method, and both create and read operations are fast JDBC operations.

2. hibernate uses UUID. HEX to construct the primary key, which has slight performance loss but is not large.

3. For the create operation, JDBC is faster than hibernate in the batch processing mode, and the JVM memory consumption for the batch processing mode is much higher than that for the non-batch processing mode.

4. Reading data. hibernate iterator is very slow because it only obtains data from the database each time next, this can also be clearly seen from the observation of the changes in memory usage of the Java Process in the task manager. The memory is increased by dozens of KB and dozens of KB.

5. Reading data, Hibernate's list speed is very fast, because it completes data retrieval at one time, which can be clearly seen from the observation of memory usage changes of the Java Process of the task manager, the memory is almost 10 MB increase.

6. JDBC reads data in the same way as Hibernate lists (this is closely related to the JDBC driver. The results will be very different for different JDBC drivers ), this can be determined by observing the memory changes of the Java Process. Since JDBC does not need to construct a bunch of cat object instances like hibernate, it occupies about half of the JVM memory usage compared with the list method of hibernate.

7. The iterator method of Hibernate is not useless. It is suitable for selecting a small amount of data from a large result set, that is, it does not need to occupy a lot of memory and can quickly get results. In addition, iterator is suitable for JCs buffering. Conclusion:

Due to the major defect of the MySQL JDBC driver, the test results become meaningless and have no reference value, but we can come up with some conclusions:

1. well-written JDBC is the fastest in any case.

2. hibernate list and iterator are applicable in different scenarios, and there is no problem of superior or inferior performance.

I personally think that hibernate iterator is the encapsulation of JDBC results, and hibernate list is the encapsulation of scrollable result. So I guess that if the same read test is performed on Oracle or DB2, if the result set is smaller than fetchsize, there should be no difference in the speed of 4; if the result set is larger than fetchsize, but not many times the fetchsize, the speed ranking should be:

JDBC scrollable result (minimum time consumed)

If the result set is very large but only some records in the result set are retrieved, the speed ranking is as follows:

JDBC result

To avoid misleading, I finally stressed my conclusion:

I. The well-written JDBC must have the best performance.

In fact, regardless of CMP, hibernate, JDO, and so on, all ORM is an encapsulation of JDBC, CMP is a heavyweight encapsulation, JDO moderate encapsulation, and Hibernate is a lightweight encapsulation. Theoretically, Orm will never be better than JDBC. Just like the running performance of any advanced language will never be better than that of an assembly language.

For the create and update operations, since common Java programmers may not use the JDBC batch function, Hibernate will show that it is faster than JDBC.

For read operations, Orm generally has a double-layer buffer, namely, the prepreadstatement buffer and the resultset buffer. However, JDBC does not have a slow-forward mechanism. When the connection pool is used, some connection pools provide preadstatement buffering and some even provide resultset buffering. However, in general, Java programmers generally do not consider optimizing the caching during JDBC writing, and this is not realistic, therefore, in some cases, The ORM will show a read speed higher than that of JDBC.

Ii. Comparison of hibernate list and iterator Methods

In the test, JDBC and hibernate want to focus on the following aspects:List and iteratorBut the result is untrustworthy due to the JDBC driver problem. However, some useful conclusions can be drawn.

The read operation involves two steps: the first step is to extract the database data, construct the result set, and put the data into the result set. The second step is to traverse the result set and retrieve each row of data.

In the list mode, all data is retrieved to the memory once and a large result set is constructed. The main time overhead is this step, the time overhead of this step far exceeds the time overhead of constructing the result set in the JDBC and iterator modes, and the memory overhead is also amazing. The traversal operation on the result set, the speed is amazing (from the test results above, the memory traversal of 0.3 million records is less than 100 ms, because this step is not affected by JDBC, so the result is credible ). Therefore, the list method is suitable for performing multiple operations on the result set, such as paging, traversing forward, jumping to the first row, and jumping to the last row.

The iterator method only obtains the record ID to the memory and does not fetch all the data to the memory. Therefore, the time overhead for constructing the result set is very small, which is less than the JDBC and list methods, in addition, the memory overhead is much smaller. When traversing the result set, iterator still needs to access the database, and all the major time overhead is spent here. Therefore, the iterator method is suitable for performing only one traversal operation on the result set, and the iterator method is especially suitable for retrieving a small amount of data from a large result set. In this case, the iterator performance is very good.

In addition, the iterator method can use the JCS buffer. When the buffer is used, the iterator traversal operation speed will not be affected by the database access speed, which is greatly improved. The Hibernate iterator JCs method should be the fastest. The Hibernate list speed is close to that of JDBC, while the hibernate iterator speed is too slow. In addition, JDBC and list are greatly affected by the fetch size. When the fetch size is greater than 50, the speed is significantly improved, while the hibernate iterator speed does not seem to be affected by the fetch size.