
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
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
Introduction to .NET Framework Programming in the
Database Engine
Important Notes on Implementation
Choosing the Right Tool for the Job
Looking beyond SQL Server 2005
Additional SQL Server 2005 Resources
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”.