Playing with Derby
For a project that I am doing for school, I decided to use Derby as the RDBMS for the application. The main reason behind this was that it can function as an embedded database. Part of the requirements that I have set out for the project is that the user should not have to install anything in order to get the app up and running. Since my program is the only thing talking to the DB, Derby is perfect.
After playing with it for the last several hours, I gotta say that I really like it. As I said, for my little application, it is perfect. It is very simple to work with and nice and quick to setup. I have only been using for a few hours, but I have already managed to get it starting up, shutting down, and loading tables all in an embedded environment. Not too bad for one evening worth of work.
One perfect use for Derby, that I can see, is unit testing. Instead of having developers, when testing their code, connect to a central database, include Derby as part of the application and, using dependency injection, sub in Derby in place of the real database. If the developer screws things up who cares cause the DB can be loaded fresh each time. The only downside to this is that I am not sure if it is supported by Hibernate. If not, I can’t see it taking much time before support is added.
If you have an application where it is only the application that needs to talk to the database, then you owe it to yourself to check out Derby.