Java Reference
In-Depth Information
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 applica-
tion 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 Win-
dows 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 gener-
ating 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.
14.7
B EYOND THE B ASICS
We are going to adopt a very simple strategy for database persistence. We are
going to read in the data structures at startup and maintain them as changes
are made during execution. That way, any abnormal termination will leave the
data in a recoverable state. The application will not require any “save”
operation.
Search WWH ::




Custom Search