Section 14.6. Being Self-Contained

14.6. Being Self-Contained

One of the common difficulties with software that requires a database is how to get the database structures up and running. Database storage is often not in files, and even when it is in files on the filesystem, you cannot, when you install a package like BudgetPro, simply put your database files in place, since there are probably other applications that have their tables in those files, and replacing them with yours would destroy that data.

Often, the table creation statements and any initial table rows required are placed in a SQL file and that file is run against the database. Meanwhile, all of the database code that performs application interactions is either in the application code or in stored procedures called by the application code. But there is no fundamental reason to make this distinction. The application can see to it that its database and tables are created.

Of course, you can automate this setup with a shell script, but Java is supposed to be cross-platform. Of course, you can write a batch file for Windows and a shell script for UNIX, but if you just put this setup into your Java code, you don't have to maintain and test separate installation procedures. One of the areas where Java applications tend to lag behind other applications is in installation and setup. You can obviate this somewhat by including database setup in your Java code, thus eliminating the need to write platform-specific scripts.

Consider including your database and table creation statements directly in your Java code, even if it is in a singleton setup class that only runs once.

The basic tables should parallel the objects. So, for our classes, the SQL statements to build the tables might look as shown in Example 14.1.

For the moment, we are confining our table declarations to a form that should work with both Open Source databases.

These are very basic definitions. We will be talking about issues like generating unique IDs for records as we develop the code to back these. Different database products have different "best" solutions, which will make the support for multiple databases more problematic.