A.1 Tables, Records, and Columns

The principal division of 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 database is organized into rows, where each row represents a single record. The rows are organized into columns. 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.