Programming ASP.NET 3.5, 4th Edition

Tables, Records, and Columns

The principal division of a database is into tables. 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, a Customer table might have columns for the customer ID (the unique ID of the customer placing the order), the name of the customer, the email address of the customer, and so forth.

It is common to make an analogy between tables and classes and between rows and objects. The Customer table, for example, tells you a great number of things about a customer, just as a Customer class does. Each row in the Customer table describes a particular customer, much as an instance of the Customer would do.

This analogy is compelling, but limited. Tables, like classes, typically describe one logical entity and all of what you know about that entity. The mapping isn’t reflexive, though—classes can contain properties that actually map across several different tables. This is similar to the notion of relationships between tables to ensure that consistent data in a database is not reflected back as relationships between classes.

One of the challenges facing an object-oriented programmer is overcoming these and other design differences between the object model on the one hand and the database model on the other. Typically, the interface between the backend relational database and the objects in the application is managed ...