在上一篇文章中，我们带您总体浏览了微软云数据库SQL Azure的基础知识和如何创建账户等内容。在本系列的SQL Azure文章中，我们将介绍关于SQL Azure开发的知识，以及它与传统SQL Server存在哪些不同。本文里，我们还将介绍关于选择云的指导方针，以及造成性能瓶颈的限制等内容，希望对您有所帮助。

　　SQL Azure技术基本上完全是基于传统SQL Server的，因此你可以利用现有的SQL Server理论知识来指导你使用SQL Azure。然而，就像我们之前提到过的，SQL Azure目前还处在第一个版本，在数据库引擎和T-SQL语言支持方面还存在着一定的缺陷，就这一点而言，你最大的问题应该是找到SQL Azure中不支持的功能，而不是一点一点抠SQL Azure的功能细节。

　　当你在充分研究SQL Azure之后，就开始重新构建你的应用吧(如果需要的话)，然后安排工作区来部署与SQL Azure相同的函数集。不用说，你数据库代码越复杂，那么部署SQL Azure的时候也就会越困难。

　　那么下面我就来介绍一些潜在的问题，这些问题是你在使用SQL Azure有限的功能集时可能会遇到的。如果你的解决方案使用了多种数据库并彼此连接的话，那么你是不可以使用SQL Azure的，因为它不提供多数据库和分布式事务支持。因此，你需要将所有的数据库合并到单一的数据库上。

　　另一个问题涉及到Service Broker，在这一情况下，你需要更改部署来创建一个队列表，插入一行数据来代替发送信息到代理队列，然后使用其它的途径来处理表中的信息。

　　关于CLR的问题。由于SQL Azure不支持CLR，因此你要么限制应用的函数集，要么在T-SQL中部署CLR相关资料。在某些情况下，这是可行的，但是同时会导致性能降低。

　　如果你想要在应用中使用SMO，SQL Azure提供的支持是有限的。因此彻底测试整个应用是十分必要的，因为它可以确保无论使用什么样的SMO对象，SQL Azure都可以支持。你可能还发现SQL Azure并不支持SQL Profiler，如果你使用这些工具进行日常的故障检测和调试的话，那么不幸地告诉你，你就必须使用PRINT语句，然后向表中插入数据，利用其他技术来完成SQL Profiler的功能。

　　类似地情况，SQL Azure中你无法调试T-SQL代码。我认为这两项限制是部署SQL Azure最大的阻碍，但是让我们期待未来的SQL Azure会提供更好的支持。因此，你最好在SQL Server中保留原有开发环境，在SQL Server中作好相应的分析和调试工作，然后再将数据库对象、数据和代码整体迁移到SQL Azure上。