Choosing a Data Access Strategy

A project team needs to consider the following questions before choosing a data access technology:

  • Is the development team creating a new design, or modifying an existing application that uses obsolete data access technology? For a modification, it's tempting to continue with the application's former data access methods, which in the short term seems like a reasonable and cost-effective decision. However, the downside involves programming difficulty as the application stretches toward new and different data sources. For a new design, developers should use ADO.
  • Where is the data? Is it on the Web, on a remote server, or simply stored locally on user systems? If the data is simply stored on users' local systems, the need to build a separate server to manage the data might be overkill. If the data is remote, what about connection management? What happens when the application can not connect? Should the application be using an asynchronous data access technology such as ADO or RDO?
  • What are the developers trained to use? Do they already have experience with ADO, RDO, DAO, or ODBC? Is it worth the modest one-time cost and effort to train the entire staff to use ADO? If the team begins using ADO, can developers reasonably anticipate a maintenance cost reduction in the near future?
  • Does an application require data access to both relational and nonrelational data sources? Do developers have an OLE DB provider for each? If so, use ADO.
  • Are developers planning to use MTS? If this is the case, developers need to choose one of the data access technologies that can be executed on the server and act as a "resource manager" (an MTS term for a component that implements its set of resource manager interfaces). For example, ADO, RDO, and ODBC can act as MTS resource managers. The DAO interface is not capable of being a resource manger. The team should also consider if the component must be thread safe, such as with ADO and RDO, since this is a requirement for most MTS-managed components if developers expect reasonable resource use and performance.
  • Does every application already use the ODBC API? If developers continue with ODBC, how will their applications access other kinds of data sources in the future?

Developers can use differing data access technologies to implement useful data access and application communication strategies; such strategies are listed in Table 9.7.

Table 9.7 Key characteristics for data access technologies

Best choice is…If the application requires…Remarks
ADO Mainframe data or programcommunications With Microsoft SNA Server, developers can set up OLE DB data providers for mainframe data sources such as VSAM, CICS, IMS, and AS/400 files.
Reengineering For existing applications, developers should consider reengineering with ADO. As an alternative, developers could continue with previous data access methods.
New development For all new development, use Microsoft's ADO data access technology.
Uniform access to a variety data sources and data types ADO is a common interface for all data access of requirements.
Fast development ADO helps minimize development cost because it is uniform, consistent, and easy to use. The team can be trained once and benefit continuously thereafter.
High performance ADO provides rapid performance.
Web: Internet Information Service's (IIS) Active Server Pages (ASP) If the application uses IIS with ASP to generate browser-independent HTML from databases, use ADO.
OLE DB Custom File Access The team can write custom OLE DB data providers for virtually any data source. Once written, ADO can then be used as the data access technology.
RDO Fast access to existing ODBC dataRDO is very fast.
ODBCDirect Access to ODBC data ODBCDirect provides a performance improvement over the older DAO data access technology.
DAO Enhancements to existing data access DAO provides a consistent programming model for DAOsituations where some of the data access services must be provided using Microsoft Jet. If developers already have large amounts of DAO code and are willing to over- look the design, coding, and performance benefits provided by ADO, there's no reason to change it.
Running within a 16-bit environment DAO is the only choice.
ODBC API Fast access to existing ODBC data If the team is willing to develop and maintain complex code using the ODBC API, this is a good choice.

Microsoft Corporation - Analyzing Requirements and Defining Solutions Architecture. MCSD Training Kit
Microsoft Corporation - Analyzing Requirements and Defining Solutions Architecture. MCSD Training Kit
Year: 1999
Pages: 182 © 2008-2017.
If you may any questions please contact us: