Evolution of database access methods

ArticleDirectory

• . NET data provider
• Namespace Structure
• General Programming

Prehistoric

At that time, every database vendor (actually few)

All have their own database operation APIs,

Each applicationProgramOnly one fixed database can be used

Want to change the database? No! You need to write all again

Later

X/open and ISO (like IBM)

How can programmers survive in such a mess?

So I proposedCLI (call-level interface)

The CLI (driver) of each database is basically the same,

Programmers are better off, but they need to change the database,

The program you write needs to be re-compiled (or installed)

Later

So ODBC came, and it passedDynamically load the CLI of each database

Converts a function call to a CLI call for each database.

The database application has nothing to do with the database supplier.

Later

Ms puts forward Ole and Ms also has its own database

(Access/SQL Server)

Ms is the boss. You must have your own opinions on this issue.

If only ODBC is provided, there is no face to face.

So I proposedOledb, which is called through the COM interface

Oledb also requires each database to provide a CLI

(But with a new term called provider)

The MS writes a provider to access and sqlserver respectively

However, to take care of ODBC, an ODBC provider is also provided.

In this way, databases that only provide ODBC can also be accessed through oledb.

However, this is a little less efficient (because it requires two layers)

Therefore, some databases now provide their own providers.

Later

Ms says oledb interfaces are too complicated.

The programmer also adjusts the query

No need to make it so complicated.

As a result, ADO is proposed to encapsulate

It simplifies the use of methods and frees programmers from operating databases.

The new century has finally arrived

Ms also invented. Net to adapt to the new trend of the new century.

Also proposed ADO. net,

I have not cleared this part of content. Which of the following adults can continue?

But I feel like I want to encapsulate it on the original ADO.

 

Figure 1. 2. Data Access Stack

. NET data provider

Ado. Net depends on the services of. NET data providers. These providers provide access to the basic data source and include four main objects (connection, command, datareader, and dataadapter ).

Currently, ADO. Net comes with two types of providers: The Bridge provider and the native provider. Through the bridge provider (such as those provided for ole db and ODBC), you can use databases designed for previous data access technologies. Native providers (such as SQL Server and Oracle providers) are generally able to improve performance, partly because an abstraction layer is missing.

•	SQL Server. NET data provider. This is a provider for Microsoft SQL Server 7.0 and later databases. It is optimized to access SQL Server, and it communicates directly with SQL Server through the local data transmission protocol of SQL Server. Always use this provider when you connect to SQL Server 7.0 or SQL Server 2000.
•	Oracle. NET data provider. The. NET Framework data provider for Oracle supports data access to the Oracle Data source through the Oracle client connection software. The Data Provider supports Oracle client software version 8.1.7 and later.
•	Ole db. NET data provider. This is a hosting provider for the ole db data source. Its efficiency is slightly lower than that of the SQL server. NET data provider because it is called at the OLE DB layer when communicating with the database. Note that this provider does not support the ole db Provider msdasql for Open Database Connection (ODBC. For ODBC data sources, use the ODBC. NET data provider (which will be introduced later ). For a list of ole db providers compatible with ADO. net, see http://msdn.microsoft.com/library/en-us/cpguidnf/html/cpconadonetproviders.asp.

Other. NET data providers currently in the testing phase include:

•	ODBC. NET data provider. The. NET Framework data provider for ODBC uses the local ODBC driver Manager (DM) to support data access through COM interoperability.
•	A hosting provider used to retrieve XML from SQL Server 2000. XML for SQL Server Web update 2 (currently in the test phase) contains a hosting provider dedicated to retrieving XML from SQL Server 2000. For more information about this update, seeHttp://msdn.microsoft.com/library/default.asp? Url =/NHP/default. asp? Contentid = 28001300.

For a detailed overview of different data providers, see ". NET Framework data providers" in the. NET Framework developer guide, which is: http://msdn.microsoft.com/library/default.asp? Url =/library/en-US/cpguide/html/cpconadonetproviders. asp.

Namespace Structure

The types (classes, structures, enumerations, etc.) associated with various. NET data providers are located in their namespaces:

•	System. Data. sqlclient. Contains the SQL server. NET data provider type.
•	System. Data. oracleclient. Contains oracle. NET data providers.
•	System. Data. oledb. Contains the ole db. NET data provider type.
•	System. Data. ODBC. Contains the ODBC. NET data provider type.
•	System. Data. Contains types independent of the provider, such as dataset and datatable.

In each associated namespace, each provider provides implementation for connection, command, datareader, and dataadapter objects. Sqlclient implements the prefix "SQL", while oledb implements the prefix "oledb ". For example, the sqlclient Implementation of the connection object is sqlconnection, while the oledb implementation is oledbconnection. Similarly, the two implementations of the dataadapter object are sqldataadapter and oledbdataadapter respectively.

In this Guide, examples are taken from the SQL Server Object Model. Oracle/oledb and ODBC provide similar functions, though not described here.

General Programming

If you want to target different data sourcesCodeTo migrate data from one data source to another, consider programming to support idbconnection, idbcommand, idatareader, and idbdataadapter interfaces in the system. Data namespace. All implementations of the connection, command, datareader, and dataadapter objects must support these interfaces.

For more information about implementing the. NET data provider, see.

It should also be noted that if the application uses a single object model to access multiple databases, both the ole db and ODBC bridge providers can be used. In this case, you need to consider how flexible the application needs to be compared to the performance needs of the application, and to what extent the database features are required.

Figure 2 illustrates the data access stack and the relationship between ADO. NET and other data access technologies (including ADO and ole db. It also describes two managed providers and main objects in the ADO. net model.