SQL Workbench: the Swiss Knife SQL Query Tool

SQL Workbench is an SQL query tool clearly built by engineers for engineers. The kind of attention these developers obviously pay to both feature design and details is really an example how professional tools should be built.

To begin with, it does not assume much about the environment. It is a Java application so it runs on most desktop operating systems and it uses JDBC to access databases, so it can work with basically any RDBMS out there. This means that you can derive value from its use in a wider set of use cases and that you don’t have to learn to use another tool to get the job done on another database.

While it is not FOSS, it does support some of the basic freedoms: the rights to distribute and use the software in any way (other than to sell it, apparently). Unfortunately, this does not include the right to modify it and it is a bit of a mystery why. I would very much like to see it released under GPLv3 or a similar licence and who knows? We might get to see the day…

It seems appropriate to start a review of an SQL query tool from its SQL handling capabilities.

Please keep settings in a database

One of the things people keep reinventing in all kinds of information systems is settings management. There are a number of ways to go about it, which is what probably confuses developers: settings can go into simple property files, XML/YAML files, structured/typed DB tables and general purpose key-value DB tables, among others.

Each of these is best under specific circumstances and it is worth looking at how things are done in really successful software.

Java uses simple property files which get packaged into .jars and are typically used as read-only mappings which are quick and simple to process and easy to understand. Providing GUI element translations in such files is a fairly sensible use of .properties files. Because no assumptions can be made about what the code does at the language level, using a database is out of the question.

Log4j used to be configured using properties files, but property files being basically maps, this was too strict a constraint to represent the richness of concepts the log4j developers wanted people to be able to express. They solved the problem by switching to XML with which they retained the immediate access to the content, sufficient readability (mostly due to limited document size) and reasonably simple processing. Again, there is no such thing as a log4j database to keep settings in so a database table is not an option.

Having said all this, it is very rare that people develop software for the x86 platform without using some kind of database.