Understand the technology you use
In the early days of databases, developers needed an intimate knowledge only of the database product they were using. But database products and technologies have advanced quickly. From relational databases to nonrelational data stores such as email and file systems, data-access technologies have had to keep up with rapid technology changes. And with the advent of client/server and multitier application architectures, developers must now understand a variety of data-access technologies. Most developers have spent years learning acronyms such as ODBC, DAO, RDO, OLE DB, ADO, and RDS. Now Microsoft has introduced the .NET Framework and, with it, another new data-access technology: ADO.NET.
As we become immersed in each new technology advance, we often forget how data-access technology has evolved and the rationale behind each technology. Understanding the progression of these technologies—from ODBC to ADO.NET—can help you choose the appropriate technology and optimize it for your organization.
ODBC
In the most basic kind of database design, applications rely on only one database. In such a simple setup, an application developer can program directly against the database system's interfaces. Although this approach provides a quick and efficient way to access data, it often poses a big problem when a business expands and the developer must scale up the application. The one-database approach also means that each off-the-shelf application must have a different version to support each database. As businesses change, grow, and merge, applications must access multiple databases running on different platforms.
ODBC technology provides a common interface for accessing heterogeneous SQL databases. ODBC uses SQL as a standard for accessing data. Figure 1, page 30, shows a diagram of a standard ODBC architecture. This interface provides maximum interoperability: One application can access different SQL database management systems (DBMSs) through a common set of code. Thus, a developer can build and distribute a client/server application without targeting a specific DBMS.
The developer can add database drivers to link the application to the user's choice of DBMS. As Figure 1 shows, the driver manager provides the intermediate link between the application and the databases. The ODBC interface contains a set of functions that the drivers of each DBMS implement. When an application changes its DBMS, the developer simply replaces the old driver with the new DBMS's driver and the application can work as usual—without the need for code modifications.
DAO and RDO
ODBC uses low-level interfaces, so C and C++ programmers are the people who really benefit most from ODBC technology. Visual Basic (VB) programmers don't have an easy way to access the ODBC interfaces. Before VB 6.0, developers had to rely on a higher-level mode of data access. Figure 2, page 30, shows how VB programmers use Data Access Object (DAO) to access databases.
DAO is based on Microsoft Jet—the database engine for Microsoft Access. Jet was the first object-oriented interface for connecting to Access. Applications that use Access can use DAO to directly access a database. Because DAO is modeled closely after Access, using DAO is the fastest and most efficient way to connect to an Access database. DAO can also connect to non-Access databases such as SQL Server and Oracle. DAO uses ODBC, but because DAO is designed specifically to talk to the Jet engine, Jet translates calls between DAO and ODBC. This extra translation step results in slower connections when you're using databases other than Access.
To overcome this limitation, Microsoft created RDO. Figure 3, page 30, shows how RDO accesses ODBC APIs directly without needing to go through the Jet engine. Before long, Microsoft introduced ODBCDirect, an extension of DAO that makes use of RDO in the background. Figure 4, page 30, shows how ODBCDirect lets existing DAO applications access databases without the performance penalty that the Jet engine creates.
OLE DB
Over the years, ODBC has become the standard for client/server database access. ODBC provides a standards-based interface that requires SQL processing capabilities and is optimized for a SQL-based approach. However, what happens if you want to access data in a nonrelational data source that doesn't use SQL (e.g., Microsoft Exchange Server, which doesn't store data relationally)?
Enter OLE DB. OLE DB builds on ODBC and extends the technology to a component architecture that delivers higher-level data-access interfaces. This architecture provides consistent access to SQL, non-SQL, and unstructured data sources across the enterprise and the Internet. (In fact, for access to SQL-based data, OLE DB still uses ODBC because it's the most optimized architecture for working with SQL.) As Figure 5, page 32, shows, OLE DB consists of three components: the data consumer (e.g., an application); the data provider, which contains and exposes data; and the service component, which processes and transports data (e.g., query processors, cursor engines). OLE DB is one API that operates against SQL data sources and non-SQL data sources such as mail and directories.
Prev. page
[1]
2
3
next page 
