A.1 Tables, Records, and Columns
The principal division
a database is into tables. Tables, like classes, should describe one
logical entity and all of what you know about that entity.
Every table in a relational
is organized into rows, where each row represents a single record.
The rows are organized into
All the rows in a table have the same column structure. For example,
the Bugs table described in Appendix B (and used in
Chapter 11) might have columns for the bugID, the
ID of the person reporting the bug, the date the bug was reported,
the status of the bug, and so forth.
It is common to make an analogy between tables and classes, and
between rows and objects. The Bugs table, for example, tells you a
great deal about the contents of a Bug, just as a Bug class tells you
about the state and structure of a Bug. Each row in the Bug table
describes a particular Bug, much as an object does.
This analogy is compelling, but limited. There is only an imperfect
match between relational databases and objects, and one of the
challenges facing an object-oriented programmer is overcoming the
design differences between the object model, on the one hand, and the
database model, on the other.
Relational databases are very good at defining the relationship among
objects, but are not good at capturing the behavior of the types
described in the table. The "impedance
mismatch" between relational databases and
object-oriented programs has led some developers to try to create
object databases. While this has met with some success, the vast
majority of data is still stored in relational databases because of
their great flexibility, performance, and ability to be searched
quickly and easily.
Typically, the interface between the back-end relational database and
the objects in the application is managed by creating a database
interface layer of objects that negotiate between the creation of
objects and the storage of information in the database tables.