Comparison of the pros and cons of JDBC and hibernate

Hibernate is a lightweight object encapsulation of JDBC, which is a stand-alone object persistence layer framework, and the app Server, and EJB have no inevitable connection. Hibernate can be used wherever JDBC can be used, such as the database access code for Java applications, the implementation class for DAO interfaces, or even the code that accesses the database in BMP. In this sense, hibernate and EB are not a category of things, and there is no either-or relationship. Hibernate is a framework that is closely related to JDBC, so hibernate compatibility and JDBC driver have a certain relationship with the database, but the Java program that uses it has nothing to do with the app server and there is no compatibility issue. Hibernate cannot be used to directly compare with the entity bean, only in the framework of the entire EE project. And even in the overall framework of software, Hibernate appears as a substitute for JDBC, not as a substitute for an entity bean, and let me once again list the frame structure I have listed n times: Traditional architecture:

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

To address the alternative architecture of performance barriers:

2) Session Bean <-> DAO <-> JDBC <-> DB

A schema that uses Hibernate to improve the development efficiency of the above architecture:

     3) Session Bean <-> DAO <-> Hibernate <-> DB Analysis on the above 3 architectures:    & Nbsp;               1, Memory consumption: JDBC-based Architecture 2 is undoubtedly the most memory-saving, Hibernate architecture 3 times, EB, the architecture of 1 the worst.                    &NBSP;2, operating efficiency: If JDBC code writes are optimized, then the JDBC schema runs most efficiently, but in real projects this is almost impossible, requiring programmers to be very proficient in JDBC, using batch statements, Adjust parameters such as batch size and fetch size for preapredstatement, use result set cache if necessary, and so on. In general, programmers can't do this. The Hibernate architecture therefore shows the fastest running efficiency. EB's architecture is far less efficient.                    &NBSP;3, development efficiency: with JBuilder support and simple projects, EB architecture is most efficient, JDBC second, and hibernate the worst. However, in large projects, especially when the persistent layer relationship mapping is complex, hibernate is surprisingly efficient, JDBC is second, and the EB architecture is likely to fail.                     4, distributed, security checks, clustering, load balancing support because there is no difference in the facade,3 architecture of SB. Iv. What is the difficulty of studying EB and hibernate? &nbWhere is the difficulty of Sp;     eb? Not on complex XML configuration files, but in the slightest careless use of EB, there are serious performance hurdles. So hard when you need 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 operation efficiency of EB. To do EB development work, most of the programmer's energy is put on the performance of EB, but there is no more attention to their own focus on the main focus on the design of the persistence layer of the object. Where is       hibernate difficult? Not in Hibernate itself complex, in fact hibernate is very simple, difficult in hibernate too flexible. When you use EB to achieve the persistence layer, you will find that EB is too clumsy, clumsy to you have no choice at all, so you do not have to spend energy to design programs, to balance the quality of the plan, to the cost of thinking about choosing which option, because only the only solution in front of you, you can only do so, No choice. Hibernate on the contrary, it is too flexible, the same problem, you can at least design more than 10 kinds of solutions to solve, so especially puzzled, on earth with this, or with that? What is the difference between these programs? How do they differ in how they operate? Running efficiency which is better? Just the primary key generation, there are seven or eight kinds of options for you to choose, you are embarrassed? Set properties can be set, can use list, can also use bag, in the end which high efficiency, you embarrassed not embarrassed? Query can be used iterator, can use list, which is good, what is the difference? Are you embarrassed? Composite PRIMARY key You can configure it directly in HBM, or you can customize the CustomerType, which is better? Are you embarrassed? For a table, you can choose a single mapping of an object, you can also map to a parent-child object, you can also map to two 1:1 of the object, under what circumstances in which scenario is better, you are embarrassed? This list can be listed all the time until you don't want to see it anymore. When you have a myriad of dazzling solutions in front of you, you will feel happy? Or is it sad? If you are a responsible programmer, then you will be careful to study the difference between each scheme, the efficiency of each scheme, the application of each scenario, you will feel that you have been caught in the pull out. If you are using EB, you have made a decision in the first second, there is no choice, such as set properties, you can only use collection, if it is hibernate, you will be in bag,list and set back and forth hesitant, even if it is unclear, the program is not able to write. Add:

JDBC has the advantage of JDBC flexibility over performance compared to hibernate. Hibernate has some advantages in easy learning and ease of use. JDBC has an advantage when it comes to many complex multi-table and complex database operations.

Same point:

Both are Java's database operations middleware.

Both objects that operate directly on the database are not thread-safe and need to be shut down in a timely manner.

Both can make explicit transactions on the database's update operations.

different points :

Different SQL languages used: JDBC uses a relational database-based standard SQL language, Hibernate uses the HQL (Hibernate query Language) language

Different objects are manipulated: JDBC operates data, passes data directly to the database through SQL statements, and hibernate operates on persisted objects, which are updated to the database by the data of the underlying persisted object.

Data state is different: the data of the JDBC operation is "instantaneous", the value of the variable cannot be consistent with the value in the database, and the data of hibernate operation is durable, that is, the value of the persisted object's data property can be consistent with the value in the database.

JDBC and Hibernate read performance

1, JDBC is still the fastest way to access, whether it is a create or read operation, is JDBC fast.

2, Hibernate uses Uuid.hex constructs the primary key, the performance slightly somewhat loses, but is not big.

3. Create operation, JDBC is faster than hibernate using batch processing, and consumes JVM memory in batch mode much more than not using batch processing mode.

4, read the data, Hibernate iterator speed is very slow, because he is each next time to go to the database to fetch data, this point from observing the Task Manager Java process Memory changes can also be seen clearly, memory is dozens of k dozens of k increase.

5, read the data, Hibernate list speed quickly, because he is a one-time to take the data out, this point from observing the Task Manager Java process Memory changes can also be seen clearly, memory is almost 10M 10M increase.

6, the way JDBC read data and hibernate is the same as the list (it is very much related to the JDBC driver, different JDBC driver, the results will be very dissimilar), this from the observation of the Java process memory changes can be judged, Because JDBC does not need to construct a bunch of cat object instances like Hibernate, it takes up about half of the JVM's memory than Hibernate's list.

7, Hibernate's iterator way is not useless, it is suitable to select a small amount of data from a large result set, that does not need to occupy a lot of memory, but also can quickly get results. The iterator is also suitable for use with JCS buffering. Final conclusion:

Because of the major flaws in MySQL's JDBC drive, the test results become meaningless and do not have any reference value, but we can probably determine some conclusions:

Well-written JDBC is the fastest in any case.

Second, Hibernate list and iterator applicable to different occasions, there is no question of which is superior or inferior

I personally think that hibernate iterator is the encapsulation of JDBC result, and Hibernate list is the encapsulation of scrollable result, so I speculate that if I do the same read test on Oracle or DB2, If the result set is less than fetchsize,4 there should be no difference in speed, if the result set is greater than fetchsize, but not many times fetchsize, the speed ranking should be:

JDBC Scrollable result (least time consuming) < Hibernate List < JDBC Result < Hibernate Iterator

If the result set is very large, but only some of the records in the result set are taken, the speed is ranked:

JDBC Result < Hibernate Iterator < JDBC scrollable result < hibernate List

To avoid misleading, I conclude by emphasizing my conclusion:

First, "well-written" JDBC must be the best performance

In fact, regardless of cmp,hibernate,jdo and so on, all ORM is a JDBC package, CMP is a heavyweight package, JDO medium package, Hibernate is a lightweight package. In theory, ORM can never be better than JDBC performance. Just like any high-level language, running performance will never be better than assembly language.

For create and update operations, Hibernate will show more speed than JDBC because normal Java programmers do not necessarily use the functionality of JDBC batch.

For read operations, ORM generally has a double-layer buffer, that is, prepreadstatement Buffering and resultset buffering, and JDBC itself has no buffering mechanism, in the case of using connection pooling, Some connection pools will provide prepreadstatement buffering, some even provide resultset buffering, but in general, Java programmers generally do not consider optimizing buffering while writing JDBC, and this is not realistic, so in some cases The ORM will show more than the read speed of JDBC.

Ii. Comparison of Hibernate list and iterator mode

The aspects that JDBC and hibernate want to focus on in testing are list and iterator, but because of the JDBC driver problem, the results are very unreliable, but some useful conclusions can still be drawn.

The read operation consists of two steps: The first step is to take the data out of the database, construct the result set, put the data into the result set, and the second step is to iterate through the result set and fetch each row of data.

The list mode is 1 times to take all the data into memory, to construct a large result set, the main time overhead is this step, this step is far more than the time cost of constructing result set in JDBC and iterator mode, and the memory overhead is also astonishing, and the traversal operation of the result set, The speed is very amazing (from the test results above, 300,000 recorded memory traversal less than 100ms, because this step is not affected by JDBC, so the result is trustworthy). Therefore, the list method is suitable for repeated operations on the result set, such as paging, traversing backwards, jumping to the first row, jumping to the last line, and so on.

The iterator method takes only the record ID into memory and does not take all the data into memory, so the time overhead of constructing the result set is small, less than the JDBC and list methods, and the memory overhead is much smaller. In the case of the traversal of the result set, iterator still accesses the database, and all the major time overhead is spent here. As a result, the iterator approach is suitable for only 1 traversal operations on the result set, and the iterator approach is particularly well suited to taking small amounts of data from the very large result sets, which iterator performance is very good.

In addition, the iterator method can be used JCS buffer, in the case of buffering, the traversal operation speed of iterator mode will not be affected by the speed of database access, and get a thorough promotion. Hibernate Iterator JCS mode should be the fastest, hibernate list speed is closer to JDBC, and hibernate Iterator speed is very slow. In addition, the JDBC and list are affected by the fetch size, and when fetch size is greater than 50, the speed is significantly increased, and the speed of hibernate iterator does not seem to be affected by the size of the fetch.

Comparison of the pros and cons of JDBC and hibernate