Always Java, Never SQL

I didn't set out on a crusade against SQL, it just sort of happened.

In reality I love SQL: it's the most successful computing language since assembler, and it makes enormous amounts of work trivial using one of the easiest syntaxes available.

All the other programmers seem to hate or, at least, avoid it tho.

I agree with some of their complaints: a huge glob of SQL string in the middle of an innocent java method is ugly and error-prone; dynamically generating SQL strings is very easy to break; and JDBC requires you to float the database schema in your head at all times.

The problem seems to be that JDBC and it's ilk are too low level. It's like using JNI but with embedded C code and constantly marshalling and unmarshalling the arguments. Obviously everyone would hate that even more that the current JNI.

The solutions that have been proposed tend to be in 2 classes: SQL hiding, and SQL written as an object.

These suffer from 2 problems: you have to know SQL; and the SQL ends up in a strange place. Either the SQL is farmed out to an XML file which is impossible to locate or read, or it is in your classes as some bizarre cross between SQL and objects making no sense to either programmers or DBAs.

The better way to do it is to translate all the SQL concepts into Java concepts and then implement them with Java style names: Why confuse the programmers with VARCHAR when you could call it String?

Amazingly everything we've look at has had an object oriented equivalent. Even complicated DB concepts like transactions have been translated: the concept is similar to a thread of execution. Now performing a transaction safely is as easy as subclassing DBScript and calling the test() or implement() method.

The change in emphasise to reveal only Java-esque names and patterns makes programming with a database as easy as using any other object.

So now I'm trying to rewrite all of the relational model into Java so no-one will ever do SQL again.

Oops.