Difference in performance of two SELECTs and a SELECT plus JOIN

Question

I searched through the web to find out how a JDBC call is transmitted to the data base management system. What I want to know is, whether a JDBC call produces network traffic in order to communicate with the DBMS, even if the data base is local?

I need to argue why two separate SQL SELECT statements are more expensive than a single one with a JOIN.

Answer 1

The simple answer is using a JDBC Driver.

The driver is platform-dependent as it makes use of ODBC which in turn depends on native libraries of the underlying operating system the JVM is running upon. Also, use of this driver leads to other installation dependencies; for example, ODBC must be installed on the computer having the driver and the database must support an ODBC driver. The use of this driver is discouraged if the alternative of a pure-Java driver is available. The other implication is that any application using a type 1 driver is non-portable given the binding between the driver and platform. This technology isn't suitable for a high-transaction environment. Type 1 drivers also don't support the complete Java command set and are limited by the functionality of the ODBC driver.

Check out more on this

I need to argue why two separeat SQL SELECT statements are more expensive than a SQL single one with JOIN.

I would say that it may depend upon on the scenario. Although it is said that JOIN will almost always be better performance. But still you may find certain scenarios(although few) where SELECT statements are preferred.

In most cases we can say that Join will usually outperform multiple single SELECTS as it enables the database to do a lot of optimizations since by using JOIN the overhead is reduced and it knows how many tables it has to scan.

Answer 2

In any scenario, the costs of passing query to the database server are negligible compared to the costs of calculating the results of your query/queries and passing them back to your application.

As @RahulTripathi mentioned, depending on the scenario, either of the latest consideration can determine which way you would want to go. Normally, the rule of thumb is to let database do what it's good at: selection, projection and joins.

Although in some cases you might indeed want to do two separate selects instead. For example, if you join tables in a way that was not anticipated by the database designer (on a column that is not a foreign key and/or to a column which is not a primary key or not even indexed) and the database is "very busy", you might be better of with 2 selects.

If you join a large table to a small table that has a lot of fields, you might want to split your query in two, especially if the second table is not changing a lot. In that case you can go even further: you can cache the records from the second table and only query the first table.

But, as I said above, you need a good reason to not use a single SELECT query.