< Zurück | Inhalt | Weiter >

14.5.4 Selection Criteria

For the simple application we are developing, all of these databases are suffi- cient. But in the real world, there could be many factors that might come to bear upon your selection of a database server product. These factors might include:

• Price

• License terms

• Transaction capacity (speed)

• Integration (does it work with or depend on other software you use?)

• Human resources (do you have operators and developers familiar with the product on your staff, or are they available for hire?)

• Presence (does your organization already use this product?)

• Features (do you have future plans that might require a particular product?)


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


image

2. http://otn.oracle.com/software/products/oracle9i/htdocs/othersoft.php


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 BEYOND THE BASICS


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.


image

Example 14.1 Candidate DB tables for BudgetPro

DROP DATABASE budgetPro; CREATE DATABASE budgetPro; USE DATABASE budgetPro;

CREATE TABLE Account ( id INTEGER NOT NULL,

name VARCHAR(64) NOT NULL,

user_id INTEGER NOT NULL, amount DECIMAL,

balance DECIMAL, parent_account_id INTEGER, PRIMARY KEY (id),

FOREIGN KEY (user_id) REFERENCES User(id)

);


CREATE TABLE User (

id INTEGER NOT NULL, name VARCHAR(64), PRIMARY KEY (id)

);


image


We will implement this in the simplest way possible, by directly embedded SQL statements in the application code. But this is far from your only choice. It is possible to design a “persistence framework,” such that all classes that inherit from a persistence base class or implement a persistence interface and follow certain naming conventions for member data can be automatically backed by persistent storage. Java’s ability to introspect, that is, to look at the names and structures of a class dynamically at runtime, allow one to write such an automatic persistence framework. Several such libraries already exist, includ- ing both commercial and Open Source options. This being an Open Source

book, we’ll call you attention to the Open Source choices:3


image

3. Have we tried all of these? Yeah. Sure. Why not? Of course we haven’t. Don’t read endorse- ment into this or any of our “here are some choices” lists. These are also not presented in any particular order. We tell you they exist. It is up to you to evaluate their suitability for your purposes.