The Database Administrator’s Guide to the SQL Server Database Engine .NET Common Language Runtime Environment

Author: Kimberly L. Tripp, Founder, SQLskills.com

Summary

SQL Server 2005 provides the database application programmer with a rich new development platform by hosting the .NET Framework Common Language Runtime environment (CLR). With new capabilities come new roles and responsibilities for the Database Administrator (DBA). This whitepaper helps the DBA determine appropriate use of this new feature and guidance on when other alternatives may provide better performance, flexibility or capabilities. As well as offering guidance on suitable uses for the Database Engine .NET Framework Programming API this whitepaper also suggests code, change and release management processes that should be tailored to each DBA’s individual circumstances to ensure a professional and safe deployment.

 

About this paper

The features and plans described in this document are the current direction for the next version of the SQL Server. They are not specifications for this product and are subject to change. There are no guarantees, implied or otherwise, that these features will be included in the final product release.

This is a preliminary document and may be changed substantially prior to final commercial release of the software described herein.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication.  Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This White Paper is for informational purposes only.  MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user.  Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document.  Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred.

Microsoft is a registered trademark of Microsoft Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

For some features, this document assumes that the reader is familiar with SQL Server 2000 features and services. For background information about SQL Server features and services, see the official product Web site at http://www.microsoft.com/sql/ or the SQL Server 2000 Resource Kit that is available from Microsoft Press.

THIS IS NOT A PRODUCT SPECIFICATION.

© 2005 Microsoft Corporation.  All rights reserved.

 



Finding the Right Tool for the Job

This whitepaper sets out to provide information to the DBA that should help them ensure successful, risk free and hence, stress-free adoption of .NET Framework programming in the Database Engine. The Database Administrator is the audience for this paper, for a more developer focused look at .NET Framework programming for the SQL Server 2005 Database Engine, see the following whitepaper on MSDN: Using CLR Integration in SQL Server 2005.

 

SQL Server 2005 provides a broad set of programming interfaces that enable developers to build robust database applications with greater ease, performance and reliability than ever before. Along with this breadth of programming options comes the need to consider which set of tools is appropriate for each task. Although many tasks can be accomplished multiple ways, each has pros and cons – so finding the best tool for the job is critical for an application to perform and scale with load and growing business usage. Some of the questions the DBA needs to ask are:

 

·         Should the system handle this data as XML or should it be shredded and stored relationally?

·         Should this process – and all of its complex pieces – be handled synchronously or asynchronously?

·         Should this business logic, this calculation or this added security option be handled in the client application, the middle-tier or the back-end database?

·         Should data analysis be handled in the relational database or through the Business Intelligence engine?

·         Should the data transformation occur with the Integration Services ETL engine or in the database using transforms built with Transact-SQL?

·         Should complex business logic – traditionally running on middle-tier servers – remain in the middle-tier or migrate to the SQL Server platform?

·         What mix of clients and servers are running in the infrastructure – is there a need to support Windows clients, Unix clients or both?

 

In most database development projects the role of technology selection and of structural design of components that interact with the database falls on the Database Administrator (DBA) – the person with final responsibility for managing and recovering that business data. Most DBAs adopt conservative attitudes to new technology. This is a natural instinct because along with the benefits offered by new functionality, new technology can introduce new risks to stability and integrity. The professional DBA usually manages the risk/benefit by ensuring that there is full testing and that they understand the new technology, taking the time to identify where it adds the most value and, perhaps more importantly, where it should not be used. As a result of this natural conservatism the DBA may ask “How do I turn that feature off until I understand it?” The good news is that unlike previous releases of SQL Server, in this release many new features are “off by default”.