Java Reference
In-Depth Information
14.2
F
OLLOW THE
O
BJECTS
One of the consequences of a good object design is a relatively simple database
design. For the most part, each class will end up as a database table where each
row represents an instance of that class. Beyond that, all that is needed are those
tables required to represent relationships between objects.
In this chapter we will show you examples of these relationships, and we
will do so in a manner that should easily port to any SQL relational database.
14.3
O
F
P
ERSISTENCE
Programs cannot be assured of running forever. Virtually all computer main
memory (i.e., RAM) is volatile, meaning that if the power is removed, the data
is lost. Since computers are sometimes rebooted, and since the power sometimes
goes out, we obviously need some place besides memory to store our class in-
stances. We need persistent (nonvolatile) storage. This can be as simple as
streaming our classes out to flat file, or it can be as complex as a clustered multi-
user database. We will discuss the selection criteria and how you might choose
your persistent storage strategy.
14.4
T
HINKING OF THE
F
UTURE
,
OR
P
AINTING IN
C
ORNERS
It is important that you try, in your class design, to avoid making the persis-
tence system dependent on a particular storage method or product. If you do
this, you can switch storage products or solutions relatively easily.
14.5
O
RACLE
, P
OSTGRE
SQL, M
Y
SQL
One of the first major decisions you must make is what to use as a database
server. On Linux systems, you have both Free Software and commercial soft-
ware options. As we have said before, we will tend to focus on Free Software
in this text, but we cannot ignore the most popular database software package
out there, which is, of course, Oracle.
Let's take a quick look at each of the “big 3” database choices on Linux
platforms.
