This question was suggested by Kyralessa in the What is your most useful sql trick to avoid writing more sql?. I got so many good ideas to try from the last question, that I am interested to see what comes up with this question.
Once again, I am not keeping the reputation from this question. I am waiting 7 days, for answers, then marking it wiki. The reputation that the question has earned, goes into a bounty for the question.
Ground Rules:
-
While it is certainly reasonable to write code, to move processing from SQL into the code to address performance issues, that is really not the point of the question. The question is not limited to performance issues. The goal is less simply less sql to get the job done.
-
Communicate the concept, so that other users say ‘Oh Wow, I didn’t know you could do that.’
-
Example code is very useful, to help people that are primarily visual learners.
-
Explicitly state what Language you are using, and which dialect of SQL you are using.
-
Put yourself in your readers shoes. What would they need to see right there on the screen in front of them, that will cause an epiphany. Your answer is there to benefit the reader. Write it for them.
-
Offsite links are ok, if they appear after the example. Offsite links as a substitute for a real answer are not.
There are probably other things to make it nicer for the reader that I haven’t thought of. Get Creative. Share knowledge. Have fun showing off.
[EDIT] – It looks like there hasen’t been any activity in a while. 5 votes = 50, so there is the bounty, and it has been wikified.
Where I work we’ve done several things to reduce SQL and to reduce the associated overhead of using SQL in Java. (We run Java with MSSQL, MySQL, and Oracle).
The most useful trick is to use Java’s setObject method for binding parameters. This, combined with Varargs, lets you write a utility method for executing SQL:
Simply iterate over the parameters and use statement.setObject(index, param[index-1]). For nulls you use setNull(). We’ve extended this concept for queries, with a getResultSet method; the wrapped ResultSet object also closes its statement, making it easier to do resource management.
To reduce actual SQL code written, we have a query building framework that lets you specify a bunch of columns and their types, and then use this to automatically specify search criteria and output columns. We can easily specify joins and join criteria and this handles most of the normal cases. The advantage is that you can generate a report in about 10 lines of code, including different query parameters, sorting, grouping, etc. The code is too complex to include here.
I’ve also used Oracle’s ALL_TABLES and ALL_TAB_COLUMNS tables to generate SELECT statements; another trick I’ve used is using the ResultSetMetadata to analyze the table:
This makes it easy to generate certain kinds of statements; in this case we have an active table and an archive table and we are moving records from one to the other. Without getting into a debate about using an archive table, the Java code I’ve written lets me modify the two tables without having to modify the archiving script.
Another trick we use is to use constants for all our table and column names. This makes typing out SQL a little tedious but it allows us to (among other things) generate SQL easily for tables with similar or identical construction. Since we use constants to define the column names the code actually enforces that the the identical columns have the same name. Using constants also lets you find references to a particular column, thus allowing you to examine other SQL statements that may be related to the work you are doing. This lets us re-use SQL from other modules, instead of blindly re-writing the same statement again.