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

Answer 1

We happen to use the iBatis SQL mapper, which is closer to the metal than ORMs like Hibernate. In iBatis you put the SQL statements into resource files (XML), which need to be in the classpath.

Your list of approaches seems pretty comprehensive if you add @ocdecio's ORM option. I would say that using an ORM and using an SQL mapper and resource files are the two best approaches. I'd steer clear from SQLJ, which hasn't seen much uptake and ties you too closely to Java. Also stay away from stored procedures, since they tie you to a specific database vendor (standards are almost non-existent for stored procedures).

Answer 2

By using an ORM (such as hibernate) you hopefully will have no SQL statements to worry about. Performance is usually acceptable and you get vendor independence as well.

Answer 3

Like most of us, I've seen the whole gammut but we need to consider SQL a first-class language. I've even seen SQL stored in the DB that is pulled down then executed back up.

The most successful systems I've seen employ stored procedures, functions and views.

Stored procs keep the SQL text back at the DB and allow for relatively immediate change by those DEPLOYING and CUSTOMIZING (which requires a lot of proper design to support it).

All projections should be via views and simple selects for the same reasons, all projection logic should be contained within the view.

Answer 4

Mine end up in resource bundles. I know it's not normal but it's the easiest for me and anyone "other than me" to maintain. It's straightforward and logical.

I'm actually curious to see if anyone uses my approach also.

Answer 5

There isn't really any substantial difference between these three:

1. Hardcoded in business objects
2. Embedded in SQLJ clauses
3. Encapsulate in separate classes e.g. Data Access Objects

I'm assuming that you're going to embed SQL code in a string form directly into your Java code. While 1 and 3 will probably use JDBC directly (or some tool like Apache DbUtils), 2 adds a preprocessor technology to the stack, generating the relevant JDBC code prior to compilation.

So, essentially, if these solutions involve embedding SQL, you might as well use any of these technologies:

• JPA Criteria API, modelling JPQL as an internal domain-specific language in Java
• jOOQ, modelling SQL as an internal domain-specific language in Java

There might also be other tools to help you embed SQL in Java in a more typesafe manner than through SQLJ or through actual string concatenation.

Answer 6

I don't know if this is optimal, but in my experience they end up hardcoded (i.e. String literals) in the DAO layer.