Java Programming - Where should SQL statements be stored? [closed]

Answer 1

Should SQL code be considered “code” or “metadata”?

Code.

Should stored procedures be used only for performance optimization or they are a legitimate abstraction of the database structure?

Stored procedures allow for reuse, including inside of other stored procedures. This means that you can make one trip to the database & have it execute supporting instructions - the least amount of traffic is ideal. ORM or sproc, the time on the wire going to the db & back is something you can't recoup.

ORM doesn't lend itself to optimization because of its abstraction. IME, ORM also means a lack of referencial integrity - make a database difficult to report from. What was saved in complexity, has now increased to be able to get the data out in a workable fashion.

Is performance a key factor the decision? What about vendor lock-in?

No, simplicity is. Vendor lockin happens with the database as well - SQL is relatively standardized, but there are still vendor specific ways of doing things.

Answer 2

SQL inside Stored Procedures is optimized by the database system and compiled for speed - that's its natural home. SQL is understood by the database system, parsed by the database system. Keep your SQL in the database if you can; wrap it in stored procedures or functions or whatever units of logic the database system provides, and make simple calls to it using any one of the tools you or anybody else has mentioned.

Why store SQL code for the database system outside the db? Often for speed of development. Why use ORM mapping? - Some say ORM mapping provides compatibility across different database systems; however rarely in the real world does an application ever shift away from the database platform upon it was built especially when it starts using advanced features like replication, and for the rare occasion it does happen that the database system is swapped out, some work is warranted. I believe one of ORM's drawbacks it often substitutes for lack of SQL knowledge or lack of care to code in the db. Also ORM will never match native database performance even if it comes close.

I'm standing on the side of keeping SQL code in the database and making simple calls to it through any API or interface you wish to use. Also abstract away the point at which your database calls are made by putting those calls behind an abstract class or OO interface (expressed by methods), so if you ever do swap in a new kind of data source it will be seamless to the business layer.

Answer 3

I suggest using DAOs with a factory layout. So the example objects you need would be:

public class CoolBusinessObject
public class DAOFactory.java
public implementation CoolBusinessOjectDAO
public class CoolBusinessOjectDAOOracleImpl implements CoolBusinessOjectDAO

This style layers the data interaction, so you should only have to change one layer of code if you switch databases, or move to ORM technologies.

Answer 4

As a rexem wrote SQL statments are code - they should be treated like code, not externalized (unles you have good reason) but placed with code that process SQL data from/to that statements. Todays framework ORMs/iBatis offer a lot of simplifications for day-to-day JDBC development.

Some answers to your question you'll find in this question:) The problem how your SQL statments will be stored depends of king of your application. What are your needs? High security, ease of writing code or maintenance, crossplatform or vendor lock-in? The next question do you need pure SQL or ORM framework will be good?

* Hardcoded in business objects
* Encapsulate in separate classes e.g. Data Access Objects

Simplest solution (P), hard to maintain (C)

* Embedded in SQLJ clauses

Beter syntax checking (P), lack od dynamic queries (C), lower perfomance than JDBC (C), no so popular (C)

* Metadata driven (decouple the object schema from the data schema - describe the mappings between them in metadata)

It must be specific case you should do that (C) or if you mean ORM (P) ;)

* External files (e.g. Properties or Resource files)

Easy to mantain (P) but harder to check for errors (C)

* Stored Procedures

High secuirty (P), code hard to mantain an vendor lock-in problems (C)

Answer 5

The fear of vendor lock-in in the java world is interesting.

I hope you haven't paid $50000 pr CPU for Oracle Enterprise, and then only used the least common denominator in order to switch to Mysql any minute. As any good DBA will tell you, there are subtle differences between the different big name databases, especially with regard to locking models and how they achieve consistency.

So, don't make a decision on how to implement your SQL calls only based on the principle of vendor agnostic SQL - have a real (business) reason for doing so.

Answer 6

The only question you ask that has a definite answer is "Is SQL code or metadata?" It is most definitely code and as such should be kept in some kind of source code control and have a system for easily updating to the latest version and rolling back when not if things go wrong.

I've seen three ways of doing SQL in an application and each has their pros & cons. There is no best way, but the best thing is just pick one that works well with your application and stick with it.

• ORM - this cuts down on the amount of SQL you need to write and handles lots of details for you. You will need to do some custom SQL. Make sure you have an ORM that handles this gracefully.
• Data Access Objects - keep the SQL in the objects that access the data. This encapsulates your database and makes it so the rest of your application doesn't need to know about the underlying DB structure, just the interface to these objects.
• Stored Procedures - this keeps all your SQL in your database and makes it easy for your DBA's to know what is going on. All you need to do is have your code call the stored procs