Hibernate Query vs PreparedStatement for SQL

Question

Hi,
I am using Hibernate for DAO classes, which i am using for the basic CRUD operations. But for complex queries with complex joins i am writing the SQL.
In such case whether it is better to use the Query.createSQLQuery(String sql) to invoke the SQL or better to use the PreparedStatement since i am invoking only the SQL as supposed to HQL by getting the connection from the Hibernate Session. Since the PreparedStatement is precompiled it may be faster than invoking the SQL through the Query.createSQLQuery(String sql)? or using the Session.getNamedQuery(QUERY_NAME)? Please let me know your opinion on this.
Thanks

Answer 1

Whether you use Hibernate, ODBC, BDE, or Funky Foo's SQL client library, Oracle does not give a damn.
It receives a statement from the client. This can either be SQL or an anonymous PL/SQL block. It parses it as a cursor. It then provides the client with a cursor handle to reference the cursor.
The cursor is essentially a program. If it has bind variables, it is a program that accepts parameter input. This allows the very same program to be executed multiple times with different input parameters. For example, executing the same INSERT SQL cursor for different values and inserting multiple rows using the very same cursor.
A cursor can also (like a program), produce output. An example is a SELECT cursor - where the fetch interface of the cursor enables the caller to consume the output of the cursor.
So what is optimal in this respect? First and foremost cursors that are created using and used with bind variables. Secondly, re-using the very same client cursor handle (and not just the same server side SQL cursor) where possible (e.g. like repeating the same SQL INSERT statement with different values).
The question to asked is whether the method you select to use on the client side - be that Hibernate or Funky Foo SQL, support this?
The consideration to make is the following. Why code SQL in the client side? SQL is executed on the server-side - refers to server side data structures and needs to be tuned on the server. Put that code in a client and it significantly increases the complexity and decrease the flexibility of SQL.
The alternative (and recommended approach) is to use PL/SQL to encapsulate all SQL. Instead of the client (and client programmer) needing to know SQL, a PL/SQL call interface is provided with calls like GetInvoice() to return a single specific invoice, or GetInvoiceByDate() that returns selected invoices for a date range. The PL/SQL code creates the SQL cursor and returns the client cursor handle as a reference cursor to the caller.
This also allows business and validation logic to be implemented in the PL/SQL call interface to protect data integrity and business transaction sanity. A database structure change requires the SQL inside a PL/SQL procedure to be changed - without having to touch the client code. Likewise, SQL can be tuned and improved without having recompile a single byte of client code. And the same PL/SQL call interface services all clients - unlike multiple Java clients duplicating the same SQL (and not always correctly) to do the same thing, or having to duplicate and repeat the same data validation and business rule logic.