ADO.NET can be used to access data from any data source: relational databases, object databases, flat files, and text files. The vast majority of web applications, however, will access data from a relational database such as SQL Server. While one can certainly write an entire book on relational databases and another on SQL, the essentials of these technologies are not hard to understand.
Tip
All of the examples in this appendix assume you are working with SQL Server and that the flavor of SQL you are using is T-SQL. Users of other relational databases will find that the lessons learned here transfer well to their environment, but be especially careful with applications like Access that use a different variation of SQL.
A database is a repository of data. A relational database organizes your data into tables that are “related” to one another. For example, one table might contain a customer’s information and a second table might contain information about orders. The tables are related to one another because each customer has certain orders, and each order is owned by an individual customer.
Similarly, you might have a table of cars and a second table of car parts. Each part can be in one or more cars, and each car is made up of parts. Or you might have a table for bugs and a table for developers. Each bug is owned by one developer, and each developer has a list of bugs he owns.
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.
Note
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.