Why OLE DB?
OLE DB exists to provide a uniform way to access all sorts of disparate data sources. For example, imagine all the types of data sources you might find in a typical organization. These might include sources as varied as production systems, file systems, spreadsheets, personal databases (such as Xbase and Btrieve), and e-mail. The problem is that each of these sources requires its own protocol. If you want to access data from a specific source, you have to learn the protocol for managing the data source. (Ugh!) OLE DB is the middle layer that provides uniform access to various data sources. With OLE DB, client-side developers have to concentrate on only a few details to get access to data (instead of needing to know many different database access protocols).The most important thing to realize about OLE DB is that it is built on COM. In other words, OLE DB is a set of interfaces for accessing data through COM. The OLE DB interfaces are general enough to provide a uniform means of accessing data, regardless of the method that is used to store the data. For example, developers use the same OLE DB interfaces to get to data without having to be concerned about whether data is stored in a database management system (DBMS) or a non-DBMS information source. At the same time, OLE DB lets developers continue to take advantage of the benefits of the underlying database technology (such as speed and flexibility) without having to move data around just to access those benefits.
As mentioned earlier, at the highest level the OLE DB architecture consists of consumers and providers. A consumer is any bit of system or application code that uses an OLE DB interface. This includes OLE DB components themselves. A provider is any software component that exposes an OLE DB interface.There are two types of OLE DB providers: data providers and service providers. The names are pretty self-explanatory. Data providers own data and expose that data in a tabular form as a rowset. (A rowset is just an abstraction for exposing data in a tabular form.) Examples of data providers include relational DBMSs, storage managers, spreadsheets, and indexed sequential access method (ISAM) databases.A service provider is any OLE DB component that does not own data but encapsulates some service by massaging data through OLE DB interfaces. In one sense, a service component is both a consumer and a provider. For example, a heterogeneous query processor is a service component. If a consumer tries to join data from tables in two different data sources, as a consumer the query processor will retrieve rows from rowsets created over each of the base tables, and as a provider the query processor will create a rowset from these rows and return it to the consumer.To sum up, there are many kinds of data and numerous ways of accessing that data in the real world, and many developers understand how to manipulate data using standard database management techniques. OLE DB defines an architecture that "componentizes" data access. As a component DBMS, OLE DB offers greater efficiency than traditional DBMSs by separating database functionality into the roles of consumers and producers. Because data consumers generally require only a portion of the database management functionality, OLE DB separates that functionality, thereby reducing client-side resource overhead.OLE DB also reduces the burden on the provider side—providers need to worry only about providing data (not about any client-side junk). For example, OLE DB allows a simple tabular data provider to implement functionality that's native to its data store and provide a singular access protocol to get to the data. That way, a minimal implementation of a provider can choose to use only the interfaces that expose data as tables. This allows for the development of completely different query processor components that can consume tabular information from any provider that exposes its data through OLE DB. In addition, SQL DBMSs can expose their functionality in a more layered manner by using the OLE DB interfaces.