With the imminent release of Windows .NET Server, we'll soon see deployment of applications built on the Microsoft .NET Framework. For DBAs and developers, the .NET Framework ushers in the next generation of Microsoft's data-access technology: ADO.NET. A marked departure from earlier COM-based versions of ADO, ADO.NET is based on XML and designed primarily to facilitate stateless n-tier Web applications. These design features, however, might be ADO.NET's greatest strengths and its greatest weaknesses.
The DataSet object is a core component of ADO.NET. DataSet is an XML-based in-memory database, complete with related tables, restraints, and relationships. Unlike the standard ADO Recordset object, which usually remains connected to the back-end database, the DataSet object operates disconnected. The closest ADO equivalent is the disconnected Recordset object—you can use a SQL query to populate both the disconnected Recordset object and the DataSet object. But the similarity between the two object types ends there. After you've populated the DataSet object, it disconnects from the back-end database, keeping the entire resultset in memory on the client. You can then programmatically create relationships and constraints for the related tables.
The disconnected DataSet object helps you build scalable Web applications by keeping locking to a minimum and freeing you from having to maintain state. However, these same features open up application-design concerns. Most important, the DataSet object's in-memory XML data store, with its own set of programmed relationships and referential integrity, is a potential black hole. If you don't implement good database programming practices, your DataSet objects could be enormous. Even today, you can trace most performance problems to an application-coding problem—typically caused by either a misunderstanding of the database design or inefficient data-access methods. ADO.NET will likely exacerbate these kinds of problems because programmers—not database designers—will now be responsible for constructing constraints and relationships. In addition, because the DataSet object handles all the application data, you must take special care when programming against large databases. DataSet shifts much of the data management to the client, which might not be able to efficiently handle vast amounts of data.
How can you eliminate these potential loopholes in ADO.NET? First, become intimately involved in the application-design process. If you're a DBA, help the database developers understand and programmatically implement the underlying database design for the application. Become familiar with application-development languages and tools so that you can understand how different ADO.NET data-access mechanisms work against the database. And review the SQL code that you use to populate ADO.NET DataSet objects to verify that applications aren't retrieving or replicating extraneous data. ADO.NET is the new kid on the data-access block, and like all new technologies, it offers some great benefits and some potential liabilities. Tying up the potential loopholes in ADO.NET could make a world of difference in the scalability and performance of your database applications.
