SQL中国研发中心

试用SQL Azure

sqlcrdft — Mon, 28 Dec 2009 08:45:00 GMT

云计算是现在很热的一个话题，很多人听说过微软的Windows Azure，它是微软基于云计算的操作系统，但微软的Azure服务平台不仅只有操作系统，它是一系列的服务，至少还包括SQL Azure和Azure Platform AppFabric。Azure服务平台即将于2010年元旦正式商用，目前可以申请试用它的CTP (Customer Technology Preview) 版。本文将对试用SQL Azure做一个简单的介绍。

要想试用SQL Azure，你首先需要一个Invitation Code，你可以通过以下网址申请https://connect.microsoft.com/SQLAzure/SelfNomination.aspx?ProgramID=2089&pageType=1 。由于目前申请的人数较多，你可以需要等待一两天才能收到邮件。

图1 申请Invitation Code的页面

有了Invitation Code，你就可以登录https://sql.azure.com/开始试用了。输入你的Invitation Code后，你就可以创建你的服务器和数据库。创建服务器步骤非常简单，如图2所示，你只需要输入用户密码即可，SQL Azure目前不支持Windows认证方式，只支持SQL Server认证方式。

图2 创建服务器

创建数据库也很简单，点击图3中的Create Database按钮后只需要输入数据库的名称和选择数据库的最大大小即可，如图4所示。这里我们输入testdb，大小1GB。SQL Azure支持两种版本的数据库，一种称为Web版，最大为1GB，商用时将每月收取9.99美元，另一种称为Business版，最大为10GB，商用时将每月收取99.99美元。

图3 数据库维护
图4 创建数据库

创建完数据库后，你需要配置防火墙的规则以允许你从远端访问SQL Azure里的服务器，图5是一个例子，我配置了124开始的IP地址都可以访问我的服务器。防火墙的规则可以需要几分钟后才能起作用，如果你连接不上，请稍等一阵再试。

图5 配置防火墙

防火墙配置完成后，你就可以从远端连接你的数据库了（也可以先使用图3中Test Connectivity按钮确认连接）。你可以使用Sqlcmd工具或者SSMS，本文将使用SSMS为例。在SSMS登录时请不要连接对象管理器（Object Explorer），因为SQL Azure中有些视图不存在，对象管理器可能无法正常工作（我的SSMS是SQL 2008 SP1）。请直接新建查询打开连接对话框，如图6所示。

图6 连接对话框

如果你想连接刚才创建的testdb数据库，你需要点击连接对话框里的选项（Options>>）按钮，并在连接属性（Connection Properties）页签里选择连接到testdb，如图7所示。SQL Azure不支持使用USE testdb来切换当前数据库。所以你必须指定数据库名，如果你不指定数据库名，你将会连接到master数据库。

图7 输入要连接的数据库名

在打开的查询窗口中，你可以输入SQL语句创建表，插入数据，或者创建存储过程，执行存储过程等等。我们将执行下面的SQL语句创建table1并插入4条数据。

CREATE TABLE [dbo].[table1](

[column1] [int] IDENTITY(1,1) NOT NULL,

[column2] [varchar](50) NOT NULL,

CONSTRAINT [PK_table1] PRIMARY KEY CLUSTERED ( [column1] ASC )

)

INSERT INTO [dbo].[table1] ([column2]) VALUES ('abcdefg')

INSERT INTO [dbo].[table1] ([column2]) VALUES ('hijklmn')

INSERT INTO [dbo].[table1] ([column2]) VALUES ('opqrst')

INSERT INTO [dbo].[table1] ([column2]) VALUES ('uvwxyz')

在用SSMS创建表并插入数据之后，我们可以用ADO.NET的程序来查询这些数据。下面是一段简单的代码在Console上打出我们刚才插入的数据。

SqlConnection conn = new SqlConnection ("Server=tcp:njix2stcmg.database.windows.net;Database=testdb;User ID=shooterlily;Password=;Trusted_Connection=False;Encrypt=True;");

conn.Open();

SqlCommand command = new SqlCommand("select * from dbo.table1", conn);

SqlDataReader reader = command.ExecuteReader();

while (reader.Read())

{

Console.WriteLine(reader["column1"].ToString() + ":" + reader["column2"].ToString());

}

reader.Close();

conn.Close();

这段代码里面最重要的部分应该就是那长长的Connection String了，不过你不必担心输错，可以使用图3中的Connection Strings按钮来拷贝，当然密码是需要修改的。编译执行，结果出来了。

图8 程序运行结果

本文简单介绍了试用SQL Azure的过程，有兴趣的读者可以参阅下面的链接来了解更多。

软件开发工程师徐进

SSIS工程师为您揭秘数据流

sqlcrdft — Tue, 22 Dec 2009 02:52:00 GMT

我上个月有幸参加了在西雅图召开的PASS（Professional Association for SQL Server）峰会。我的同事Matt Masson做了个关于SQL Server 数据集成服务（Integration Services，SSIS）的讲座（下载），现场非常火爆，讲完后他被听众围住了个把小时。他的题目是Maximize Your SSIS Investment with Tuning Tricks and Tips，主要关于提升数据集成包（package）的性能。他讲了四部分，其中第二部分深入浅出地介绍了SSIS数据流（Data flow）。我估计我国的用户会特别感兴趣这一块，因此在这里分享给你 :-)

数据流一瞥

SSIS的引擎（engine）是内存式（in-memory）的：从源（source）读数据，在内存中执行package，再把结果写到端（destination）。尽量不碰外存是其高性能的原因之一。很多以前使用ETL（Extract-Transform-Load）工具的人需要对此调整观念：那些工具先把数据加载到数据库里再做SQL转换，其实是ELT（Extract-Load-Transform）。Matt讲了个很有趣的案例：有位客户的package以前运行只要几分钟，自从服务器升级到新机器后竟然更慢了，要花一个小时。那个package很简单，只是源到端拷贝，中间没有转换（transform），因此客户很生气。Matt他们急忙去会诊，才发现这个package的源和端以前就在它所运行的那台机器上，在美国；后来升级了的机器在中国，源和端都跑到了中国来，而package还是在美国那台机器上运行。结果这个package所做的就是从中国读出若干GB的数据到美国的内存，再拷回中国……Matt说，类似的客户问题其实并不少见。希望你读本文以后能避免这种设计了 :-)

SSIS在设计时（design time）阶段就确定了数据流的元数据（metadata）。它在运行之前就精确知道了运行时的列将有多宽，转换需要多少内存，等等。

数据流水线（pipeline）

当数据流启动时，源就开始把一行行数据填到一个类似桶的缓存（buffer）中。源根本不知道下游是什么。一旦缓存满了，桶就随着流水线流到下游组件（component）上，同时引擎抓一个新的空缓存过来给源。源根本不知道这一切，它只是不断地填桶。有时源填了太多的桶，转换和端都来不及应付了；此时引擎会启动反压（backpressure）机制，让源睡眠。等到流水线又有空间之后，源被唤醒继续填桶。其实在实现上，源甚至都不知道自己被催眠过（好可怜）……直到所有源数据行都发光了，源才在最后一个缓存上贴个“行集末（End Of Rowset）”的标签，把它发出去，告诉下游组件再没有新数据了。

转换与缓存拷贝

SSIS的高性能有部分归功于它在内存使用上比较聪明。在缓存之间拷贝数据是耗时的，因此引擎会尽量减少缓存拷贝。按照缓存使用的不同，可将众多转换组件分为三类。

第一类是同步（synchronous）转换，它们一般逐行对数据做就地修改，从不拷贝缓存。它们有可能增加新行，比如数据转换（Data Convert）和派生列（Derived Column）转换，而仍然是同步的：引擎事先确定了新列将加在哪里，提前就在缓存里加了空列，只是上游组件看不到这些空列罢了。异步（asynchronous）转换会动态创建新缓存，包括两小类: 部分阻塞（Partially Blocking）转换，一伺新缓存满了就把它输出，比如联合全体（Union All）组件接受多个输入流，一旦从各输入得到了足够多的行就把它输入到一个新缓存里。由于要拷贝数据，这种转换比同步转换慢；但和全阻塞（Blocking）转换相比就好多了。排序（Sort）、聚集（Aggregate）这些全阻塞转换在接收完所有输入行之前，是不会输出一行的。这是由运算本身的特点决定的：不到看到所有数据，是无法确定哪个是最小值的。

因此，在使用全阻塞转换时要格外审慎，尤其是数据量很大时。一旦内存用完，缓存被置换到硬盘上，性能就完了。要想提高数据流性能，最好设法从package中去除全阻塞转换。

线程机制

要理解数据流，还需要了解其线程机制。流水线在运行时被分成若干执行树（Execution Trees）。每个创建新缓存的组件就是一棵新执行树的起点；因此起点要么是个数据源，要么是个异步转换。下图的数据流中有5棵执行树，如蓝箭头所示。引擎限定了每棵树中最多工作的缓存数（目前定为五个），一旦更多缓存进来，就启动反压。注意到多播（Multicast）和条件分割（Conditional Split）转换都是同步的，它们在分割数据流时并不创建新缓存；引擎只是创建了一些能映射到同一块内存的虚拟缓存。所以即使你多播20次也不会看到内存消耗增多。

此图修改自Matt的幻灯片

值得一提的是，数据流线程调度在SQL 2008版本中被改进了：在2005版中，每棵树只分到一个线程执行，其问题是对于图中右边那种较长的树，虽然树里都是一序列同步转换，但每次只能在树中移动一个缓存，执行完它之后才能开始执行下一个缓存。很多人为了打碎较长的执行树，就在中间插入一个单输入的联合全体（Union All）组件，由于它是异步的，就能间接引入另一个线程。而现在，我们在2008版中改为让每个缓存上都有一个线程在执行，这样一棵树中就可以有多个线程在执行。可能第一个线程先把一个缓存进行了三个转换，然后第二个线程捡起这个缓存继续向下游转换，同时第一个线程开始捡起下一个缓存。这样就再也不需要上述间接的方法了。

看完以上揭秘，你有收获吗？

杨珂，SSIS软件开发工程师

MSXML XHTML DTDs——使互联网更美好

sqlcrdft — Wed, 02 Dec 2009 06:11:00 GMT

微软刚刚发布了一个新的Windows升级包以改善MSXML组件解析XHTML时对W3C服务器的访问。Windows Update自动更新服务应该已经向你推送了这个升级包，不过你也可以通过以下网页手动下载适合你的版本：

http://support.microsoft.com/?kbid=973688（MSXML4 SP2……如果你还没升级到SP3的话！）
http://support.microsoft.com/?kbid=973685（MSXML4 SP3）
http://support.microsoft.com/?kbid=973686（适用于WinXP SP2和Win2K3的MSXML6独立安装版本）
http://support.microsoft.com/?kbid=973687（适用于所有随Windows发布的MSXML3和MSXML6）

这个升级包究竟是干什么的呢？让我们来看看这么一个场景：网页通过AJAX访问远程主机上的XHTML资源，把内容读入XML文档，然后获取部分信息或者把信息追加到当前网页中。很常见的场景，对不对？

问题是，当你通过MSXML读取XHTML的时候，如果没有关闭DTD处理，那么XHTML中的DOCTYPE声明会指引MSXML读取XHTML DTD以便使用 之类的实体。可以想象，当许多人访问那些使用AJAX的热门网站时，会对DTD服务器产生多少的访问量。一旦DTD服务器过载而不再响应服务的时候，便会发生各种各样的问题，比如：网站由于无法访问资源而导致服务中断、W3C承担更多的维护工作、用户由于诡异的脚本错误而无法正常访问网站，等等。

这个升级包就是为了解决这个问题而发布的。升级以后的MSXML组件将那些XHTML DTD保存起来，当需要的时候直接返回保存起来的版本，以避免对W3C服务器的访问。这些被保存起来的XHTML DTD已经稳定发布好多年了，新的实体将会在其他的URL中发布，所以你不必担心DTD的使用会受到影响。

尝试着运行以下脚本：

function pullXHtml() {

var xml = new ActiveXObject("Msxml2.DOMDocument.3.0");

xml.async = false;

xml.loadXML(

"<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Transitional//EN\" \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\">" +

"<html xmlns='http://www.w3.org/1999/xhtml' xml:lang='en' lang='en'><head><title>simple document</title></head>" +

"<body><p>a simple paragraph</p></body></html>");

if (xml.parseError.errorCode != 0) {

var myErr = xml.parseError;

WScript.Echo("You have error " + myErr.reason);

} else {

WScript.echo("Yay!");

WScript.echo(xml.xml);

}

pullXHtml();

如果你没有安装最新的升级包，你或许会遇到如下错误提示：

You have error The server did not understand the request, or the request was invalid.
Error processing resource 'http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd'.

不过，如果你安装了最新的升级包，你将会欣喜地发现XML被成功读取并解析。更进一步，如果使用Fiddler监视网络流量，你更会惊喜地发现访问没有产生任何网络流量！

Marcelo Lopez Ruiz

TechEd 2009 SQL Server动手实验答疑

sqlcrdft — Mon, 23 Nov 2009 08:02:00 GMT

TechEd2009上的SQL Server动手实验得到了广大学员的欢迎，不但积极与讲师们互动，还提出了许多高质量问题。在这篇博文中，我们总结了一些代表性的问题与大家共享。

问：SQL分区的最佳实践是什么？微软建议一个SQL Server上有多少个分区最佳？是10-100么？每个分区的最佳的大小是多少？
答：尽管分区表最多可以分成1000个分区（详见http://msdn.microsoft.com/en-us/library/ms143432.aspx），但数据库的性能和空间达到最佳优化的时候，应该是某一个平衡点，因为分区过少或过多都会有额外的开销。建议是根据具体条件，首先建立一个基准配置环境和基准性能尺度作为参考，然后逐步改变分区数和/或分区大小，分析变化，然后逐步找到最佳点。

问：在SQL Server 2005/2008上，当一个存储过程执行返回千万行的时候，SQL Server会占到16G的内存。有没有一个方法能让SQL Server自动的释放内存？
答：SQL Server能够很好的管理和使用所分配的内存。需要更多可用内存时，SQL Server会自动根据最旧最少使用的算法分配一些内存。当系统内存不足时，SQL Server也会自动释放一些内存。不建议使用DBCC FREESYSTEMCACHE或DBCC DROPCLEANBUFFERS等命令释放内存，这样会严重损坏系统的总体性能。

问：在SQL 2005上，对一个视图做了一个索引，但是当查询表的时候，在执行计划中，查看到那个视图的索引被采用了，这是怎么回事？
答：SQL Server查询优化器会根据索引和统计自动选择最佳的查询执行计划。

问：有一个网站每天有大量的日志，大约每天3G。用户希望把这些日志数据保存到SQL数据库中然后进行分析，SQL server有相关的解决方案么？听说MySQL有类似的方案 :-)
答：可以使用SQL Server对网络日志进行分析。建议是按照日志格式建立表，然后BULK INSERT日志到表中，然后可以用SQL Server Analysis Service进行数据分析。详细步骤请参考http://support.microsoft.com/kb/296085。

问：有没有一个方法把一个表的数据存放在一个指定的数据文件中？用户的场景是这样的：有一个数据量很大的表，用户希望将经常查询的数据放在一个高速磁盘上，将很少查询的数据放在一个低速的磁盘上。注意，随着时间的推移，常用的数据会变成不常用的数据，但是，SQL Server表的分区只支持在同一个分区内进行切换（SWITCH），而且，在一个分区中，无法指定将数据放到哪一个文件中，当一部分常用数据变成不常用数据时，如何将这部分新的不常用数据移到低速磁盘上？
答：SQL Server的表是基于文件组进行管理的。建议的解决方案有以下两种。第一，可以先创建一个文件组，然后在那个慢速磁盘上创建一个文件并归到这个文件组，然后用create table on filegroup 的语法方式创建表，最后将数据从表中迁移过来。第二，以2007年、2008年和2009年数据为例，可以先创建一个文件组FileGroupA，然后在那个慢速磁盘上创建一个文件并归到这个文件组FileGroupA，然后在这个文件上建表和分区PartitionA，如图1；然后SPLIT分区，从V1到V1+V2，将数据2008、2009分开为FileGroupB和FileGroupC上的分区PartitionB和PartitionC，如图2；最后合并MERGE分区PartitionB到PartitionA，如图3。

问：分析服务的备份和恢复时，选择文件路径的窗口没有 [浏览 … ] 功能，只支持用户手动输入。
答：这个问题已反馈给产品组。

曾屹林默

精彩的微软技术大会（TechEd）- 你去了吗？

sqlcrdft — Wed, 11 Nov 2009 09:28:00 GMT

每个微软技术大会（TechEd）对我来说都具有特别的意义。因为在这个里，我能遇到许多对微软技术有浓厚兴趣和热情的朋友们。在这个里，我们一起互动，一起讨论微软的最新技术。今年IT朋友们都共聚在北京的国家会议中心参加微软技术大会。

在这三天里，SQL Server 团队的讲师们也与大家分享了许多对云端数据库（SQL Azure）、商业智能（Business Intelligence）、数据库管理、虚拟化和跟踪及排错的最新发展。今年商业智能的巨人Donald Farmer 也前来赴约。Donald与大家分享了数据挖掘的技术和自助式商务智能。从数据挖掘的讲座中，大家深入了解如何应用数据挖掘的技术在 SQL Server 动态数据库管理视图(DMV) 的数据中找出异常。从自助式商务智功能的讲座中，Donald 介绍了自助式商务智能的重要性和PowerPivot 如何让熟悉Excel 的用户分析海量的数据。在演示中，大家都对PowerPivot 如何快速的分析了一亿行数据叹为观止，不约而同的热烈拍掌！

微软技术大会（TechEd）结束了！但我深信参加大会的朋友们都增加了对微软技术的了解与热情。真棒！

项目经理
卓伟雄

我们TechEd见

sqlcrdft — Tue, 03 Nov 2009 07:25:00 GMT

2009年微软技术大会（TechEd）中国下周就将在北京召开了，SQL Server中国研发团队将派出多位项目经理、软件设计开发工程师和软件测试开发工程师，与中国程序开发者和IT从业人员分享我们最新的产品开发。以下是我们负责的课程、动手实验室和专家交流区列表，希望能在大会现场与大家面对面交流。

针对程序开发者

时间

课程标题

主讲人

课程简介

11/7

15:50-17:00

BAP302
SQL Server 2008 R2的自助式商务智能(英文课程)

Donald Farmer

卓伟雄

类别：商务智能及商业应用平台
本讲座将为您详尽介绍R2中的BI新特性，以及Gemini中的个人商务智能

针对IT专业人士

时间	课程标题	主讲人	课程简介
11/6 8:00-9:10	DAT331 先睹为快微软云计算数据库平台 -- SQL Azure	吴中伟李刚毅	类别：数据平台管理与开发本讲座将为您介绍清晰而全面的SQL Azure信息包括SQL Azure的架构、基本概念、目前支持的各种功能等。
11/6 13:00-14:10	DAT201 SQL Server 2008 数据库引擎: 产品发布十五个月后	王枫	类别：数据平台管理与开发本讲座将对SQL Server 2008针对数据库引擎的主要新功能作一个全面的介绍。
11/6 14:25-15:35	DAT221 SQL Server 2008 虚拟化和最佳实践	吴家震	类别：数据平台管理与开发本讲座通过大量实例和实践的分享，从测试数据和真实场景中让您对SQL Server2008 虚拟化有个全面而深入的了解。
11/7 8:00-9:10	DAT313 如何使用SQL Server 2008 Extended Events 进行跟踪及排错	林默	类别：数据平台管理与开发本讲座将为您介绍SQL Server Extended Events特性，内部架构以及如何使用它分析问题。

时间	动手实验室标题	主持人	动手实验简介
11/6 10:50-12:00	DATHOL127 集成Microsoft SQL Server 2008空间数据支持的Microsoft Virtual Earth	赵振宇尹鸿岩	类别：数据平台管理与开发（动手实验室）本讲座主要通过实例让您了解SQL Server 2008空间数据(Spatial Data)的强大。
11/6 9:25 - 10:35	管理Microsoft SQL Server的分析服务	曾屹尹鸿岩卢雷	BAPHOL118
11/6 14:25 - 15:35	Microsoft SQL Server 集成服务：从中级到高级	卓伟雄卢雷	BAPHOL147
11/7 13:00 - 14:10	Microsoft SQL Server 2008数据仓库的分区	曾屹曹林林	DATHOL237

此外，11月7日 14:25至15:10还会有SQL Server研发团队交流会，欢迎光临。

微軟實習經驗分享

sqlcrdft — Mon, 31 Aug 2009 09:56:00 GMT

撰文者簡介：Marcus，是土生土長於香港、半諳普通話的二十歲小伙子，正於香港中文大學修讀計算機科學與工商管理雙學位課程。2009年暑假，他加入了上海微軟的SQL Server Manageability團隊作為期兩個月的實習。

時間有如白駒過隙，兩個月的實習已近尾聲。從香港乘風來到上海、體驗微軟工作喜與樂、感受上海風土人情──一切一切，盡皆難忘！特撰此文，以初生之犢的眼光記下這兩個月的實習經驗，既為個人收藏，也與大眾分享。

在巍峨的山岳中貢獻碎石

記得實習第一天的下午，我的上司Shirley跟我作了一次的迎新詳談，向我仔細描繪我未來兩個月的工作的藍圖。那個時候，我對SQL Server一無所知，不過先把工作接下來好了，也著手開始學習使用它。

第一天接觸SQL Server，覺得它就像是一座巍峨的山岳──它高聳入雲、綿延千里，其結構之嚴謹、功能之強大、目光之遠矚，實在令人望而生畏。作為SQL Server的門外漢，真的不知如何入手，更遑論要計劃為它加添新的功能了！

投入實習工作一段時間以後，仍覺得它深不可測，卻也漸漸地覺得它平易近人多了。說到要為它貢獻一項新的功能，少不免有點膽怯，但我已經有勇氣下定決心要把這項功能做好。經過實習的第三個星期的團隊內部批閱、第五個星期的外部批閱以後，我們基本上議定了這項功能的定位；在第八、第九個星期的兩次文檔批閱以後，規格文檔也算是完成了。我自問已經在自己能力範圍以內把工作做好，算是對得起自己了吧！

縱使我所訂下的功能，只是整座山脈的一塊碎石、甚至可能只是在山腳邊的碎石堆裏的其中一小顆，但我真切的感受到：微軟花這麼多的人力物力構築的宏偉的山巒，是為了讓我們的顧客站得更高，看得更遠。

十月懷胎、誕下孩子

我所體驗的Program Manager（PM）的工作，就是在獲悉顧客群對產渴求的一項功能後，對這個功能作完整及準確的定位，並書寫一份便利軟件開發工程師們工作的規格文檔。據悉，PM的其他的工作還包括成本考慮、哪個小功能會留下或者刪掉、協調團隊與團隊之間的合作之類；不過作為一個只待在這裏兩個月的實習生，暫時沒能力也沒時間一嘗這些工作的滋味呢。

在兩個月實習期裏面，我就是從我的上司口述的一個概念開始，悉心計劃、評估顧客實際需要、研究可行性、對功能作精確定位、讓同事們檢閱定位是否恰當、書寫一份二三十頁的文檔、再多次批閱……以往作為使用者的我，怎麼也看不出就是一個小功能，背後的工作居然是如此繁多！

如果說，一項功能是孩子，那麼我感到我所做的，跟諸位十月懷胎、誕下孩子的媽媽一樣。看著孩子在懷裏漸漸成形，開始感到他滾來滾去、淘氣地踢踢，那種喜悅實在是不能言喻的。其他的同事，或溫言軟語，或強烈表達，都是為了讓我這位媽媽做得更稱職，讓孩子有更好的未來。實習期太短了，我沒有辦法看著孩子出生、茁壯成長、長大成人，然則這種看著孩子長出個雛形的喜悅，非筆墨所能形容。

結語

兩個月的實習快結束了，很感謝我的上司與導師Shirley對我的關懷與悉心指導。也感激團隊其他成員對我的包容、幫助、支持與鼓勵。日後SQL Server於我來說，不再只是一個產品了──它是活生生的回憶，是一段難忘的歲月，也是一張張的笑臉。

白德全

Balisage 2009标识技术会议（六）

sqlcrdft — Tue, 25 Aug 2009 10:09:00 GMT

第三天（8/13/2009），下午

关键词：SIMD，XML，高性能处理

首先让我揭开上篇文章里的谜底，那是一只笔（右图），有兴趣的读者可以bing一下“PenAgain”。

今天中午，和其他与会者一起用午餐，我有幸认识从加拿大温哥华专程前来参加Balisage 2009的西蒙•佛雷泽大学（Simon Fraser University）计算机科学系的罗伯特D. 卡麦隆教授（Dr. Robert D. Cameron）。他很高兴地给我介绍了他和他的学生一起正在研究的项目，简而言之是利用现在愈来愈受到关注的CPU支持的SIMD（single instruction，multiple data）[1]指令集提高XML文件的处理速度。

想了解这究竟是一项什么样的技术？得先了解什么是SIMD，所谓的“单一指令，多数据”，也就是说CPU可同时在一个集合的数据上同时执行同一条指令。这个技术现在被广泛运用在计算机的图像处理单元（GPU），而越来越多的主流CPU也具备了类似的功能。我们拿Intel最新i7架构的CPU举例，它支持SSE（Streaming SIMD Extensions）4.2指令集，内置多个128位专门用于SIMD的寄存器。也就是说，可以将16个字节的ASCII数据或是8个双字节的Unicode数据载入一个128位的寄存器，然后同时对这128位数据进行查询，索引，位操作等功能。

而让我大开眼界的是，卡麦隆教授的项目组通过他们的不懈努力终于研究发明了一项独特的技术，称为parabix（Parallel bit streams for XML™）[2]，它利用位加法可以充分利用SIMD的优势成倍地提高XML的处理速度，而这项技术更可以广泛运用在其他数据处理领域，比如他们写的UTF8到UTF16的转码程序可以平均使用0.9-6.8个CPU时钟周期处理每字节数据，速度是标准的UNIX下字符编码转换程序iconv的十倍。

经卡麦隆教授允许，我在这里借用parabix公开的技术资料[3]中的内容给读者来介绍一下SIMD位加法的基本概念。假设我们有一窜XML字符数据，如表中所示，我们想做的是找出字符串中所有用“&#数字序列；”表示的Unicode特征项：

原数据共16字节，以下均采用SIMD指令。	1ऩ&#67:89a
第一步：将字符串反转，因为Intel是little-endian	a98:76#&;5432#&1
第二步：采用字符串查找指令找到所有数字	.11.11...1111..1
第三步：找到所有“&#”，对应位置1	......1......1..
第四步：将第三步结果左移一位	.....1......1...
第五步：将第二步与第四步结果相加	.11100..10000..1
第六步：将第五步结果和第二部结果取非值相异或	...100..10000...
第七步：将第六部结果减第四部结果	....11...1111...
第八步：找到所有“;”，对应位置1	........1.......
第九步：将第六部结果和第八步结果相异或	...1............

经过以上运算，由第七步找到两个可能的特征项，而第九步结果表示其中一个是错误的，并提供了具体错误的位置。

我想通过以上的介绍，你一定会和我一样为SIMD技术在XML和其他数据处理领域所能发挥的作用而鼓舞。

网络参考链接：

Balisage 2009标识技术会议（五）

sqlcrdft — Thu, 20 Aug 2009 14:35:00 GMT

第三天（8/13/2009），中午

关键词：会场内外，花絮，纪念品，开小差

连续几篇都是讨论技术的话题，我想在这篇博客里改变一下，写一些会场内外的见闻。在前面说起Balisage 2009会场设置在Best Western Europa酒店（右图，由maps.bing.com的3D地图生成）。会议组织者包了也许是这小个酒店所有可供会议使用的多功能厅（其实只有两个）。都说北美洲有很好的互联网接入服务，但是第一天，酒店还是颇费了一些周折才为所有与会者提供了无线网络连接。

我曾经提起，这个会议是一个从业人员相互切磋的盛会。会议的组织者采用很多方法来促进与会者的交流，不仅提供免费早餐，会间休息的茶点等等，还在主会场四周的墙上提供空间给与会者张贴大幅学术和产品介绍，其中有一块区域取名为“会场里听到的”（Heard in the Halls），类似BBS（左图），上面钉了好多写着一两句话的便条，都是与会者们听到和想到的。比如“By real world，I mean my world”（所谓真实的世界，我指是我的世界），“Developers do not just interpret roles；they make rules”（开发者不仅解释法则，而且创造法则），诸如此类。第一次参加这个会议的我可以感觉到，虽然参加这个会议的学者和业界人员虽然来自不同国家和地区，但似乎他们互相都特别熟悉，讲演间隙往往三五成群手里端着饮料继续讨论。到了下一场讲演开始的时间，有个热心的会议组织者会绕场一周，一边走一边挥动手里的铃铛，提醒“时间到了，请回座。”

说起大会的纪念品其他也没有什么特别的，无外乎是些印有Balisage 2009字样的贴花，徽章，小包，但是其中有一件却让我爱不释手，着实领略了一下这个会议的与众不同之处。读者可以猜一猜一旁的插图中是个什么物件，我这里先不揭示谜底。

今天下午，我一到会场，大厅里一排排整齐的桌子上放着许多刻成一个个名片大小方格的卡纸。有些已经被裁成了一张张小卡片。每张小卡片上印有一串跟XML 或标识语言有关的关键字或符号，每张小卡片有一个号码，不同号码对应不同的字符串。我实在搞不清楚这些卡片除了收集来做纪念品外还有什么用处。之后才发现，那些与会的业界专家其实也会在听讲演的时候开小差，拿这些卡纸做起手工来。

Balisage 2009标识技术会议（四）

sqlcrdft — Tue, 18 Aug 2009 16:03:00 GMT

第二天（8/12/2009），下午

关键词：管道，流处理，XSLT 2.1，推与挽模型（Push and Pull Model）

在我的书架上有两本非常醒目的红色封面参考书，XSLT 2.0[1]和XPath 2.0[2]，这两本书的作者Michael Kay的讲演内容就是今天下午我想着重向大家介绍的。

会议安排了Michael连续两个主题讲演。第一个是关于“基于管道的XML处理”（Pipeline based XML processing）[3]，第二个是“制定中的XSLT 2.1标准的流处理功能”。基于管道的XML处理所指的是在对XML的处理过程中需要经过一系列的步骤，而这些步骤实际上可以通过管道（pipeline）采用流的方式处理，当然前提是这个处理的每个步骤都需要支持“流”（streamability，这个英文单词是XSLT标准制定工作组自创的）。而所谓基于“流”的处理是指一个相对内存来说巨大的XML文件可以被分割成比较小的单元进行顺序处理。而这样的单元可以是每一个SAX [4]的消息，例如startElement和EndElement，或者是一个XML的部分，比如一个节点（Node）和原子化的量值（Atomic Value）。

而对于XML的处理来说，一般只有两种方式：组构和析构（compose and decompose）。每个步骤则采用“推”或“挽”的方式对XML组构或析构。在将这些步骤连接起来的时候由于它们各自的极化方式不一样（“推”或“挽”）或对XML的单元访问方式不一样（顺序，乱序，或在一个子树中乱序，子树与子树间顺序），要么需要一个控制器（controller）将“推”模型和“挽”模型连接起来，要么需要将XML的子树或全树缓存在内存中，结果往往造成整个处理流程的效率降低。Michael举了一个他自己的XQuery处理器例子，由于使用控制器和两个线程将“推”和“挽”两个步骤联系起来，结果比起一个单一“推”或单一“挽”的处理流程效率降低了差不多45%。会后有人提问有关在多核的系统中，是否这样的架构会体现出优势，Michael表示肯定。另外，他介绍了一个非常有用但被人淡忘的概念[5]，其实所谓的“推”或“挽”模型是可以相互转换的，在多线程的代价比较大的环境里，使用“协同程序”（co-routine）的方法可以在单一线程的条件下将“挽”模型转变为“推”模型，反之亦然。

XSLT 2.1的流处理功能是Michael应邀添加的新讲座，类似在音乐会里的加演节目。作为XSLT标准的编辑（editor），Michael对于这方面的内容当然非常熟悉。由于这篇博客的长度有限，我无法深入介绍XSLT 2.1的流处理功能，况且许多标准的细节还在起草阶段，这里就一些有趣或有争议的功能稍作解读：

xsl:stream语句的引入
新标准引入xsl:stream语句，用户使用该语句表示希望在xsl:stream之内的转型采用“流”处理方式。有人在会后提出疑问，认为这个语句将使用或不使用“流”处理的决定权交给用户，而用户往往不清楚自己设计的XSLT程序是否真可以采用“流”处理。理想情况应该是用户使用现有的XSLT语句，而“聪明”的XSLT处理器能够通过静态分析找出可以进行“流”处理的局部转型或全面转型。这其实也是XSLT标准工作小组一直在争论的话题。
xsl:iterate系列语句的引入
新标准引入xsl:iterate语句，它同xsl:for-reach语句有一样的语法结构，但是用来在“流”处理中支持可以进行尾递归优化的迭代循环和变量传递。举个例子，比如我们希望计算一个财务报告中的累计总计（running total），用传统的XSLT 1.0的xsl:for-each 将会效率特别低，堆栈内存使用为O(n)，而即使是支持尾递归优化的XSLT 1.0处理器也需要大约O(N^2)的时间（O(1+2+…+N) = O(N(N+1)/2)）。而采用xsl:iterate语句的“流”处理可以将堆栈内存减少至O(1)，时间减少至O(N)。写出的XSLT语句类似这样：
<xsl:stream href="accounts_10gb.xml">
<xsl:iterate select="transaction">
<xsl:param name="running-total" select="0"/>
<running_total><xsl:value-of select="$running_total"/></running_total>
<xsl:next-iteration>
      <xsl:with-param name="running-total"
          select="$running-total + total"/>
      </xsl:next-iteration>
</xsl:iterate>
</xsl:stream>

XSLT 2.1还引入了xsl:mode语句，它同xsl:template的“mode”属性一起用来标识某个XSL的模板是否适用于“流”处理；引入了xsl:merge语句支持多个XML文件的相互融合，这里就不一一细数了。希望了解更多XSLT最新情况的读者可以关注一下XSL标准的官方网站[6]。

http://www.amazon.com/XSLT-2-0-Programmers-Reference-Programmer/dp/0764569090
http://www.amazon.com/XPath-2-0-Programmers-Reference-Programmer/dp/0764569104
Kay, Michael. “You Pull, I’ll Push: on the Polarity of Pipelines.” Presented at Balisage: The Markup Conference 2009, Montréal, Canada, August 11 - 14, 2009. In Proceedings of Balisage: The Markup Conference 2009. Balisage Series on Markup Technologies, vol. 3 (2009). doi:10.4242/BalisageVol3.Kay01. (http://www.balisage.net/Proceedings/vol3/html/Kay01/BalisageVol3-Kay01.html)
http://en.wikipedia.org/wiki/Simple_API_for_XML
http://en.wikipedia.org/wiki/Coroutine
http://www.w3.org/Style/XSL/

Balisage 2009标识技术会议（三）

sqlcrdft — Sat, 15 Aug 2009 12:29:00 GMT

第一天（8/11/2009），中午

关键词：赤脚大仙，XML，命名空间（Namespace）

“大家都能认出Liam Quin，因为他赤着脚。”会议主持人这样介绍上午最后一个上台的演讲者。

我是几年前在德国海德堡的W3C印刷研讨会[1]上第一次认识Liam的，如果没有记错的话，当时他也光着脚走来走去，可见他多么会为他自己的私人技术咨询公司（Barefoot Computing）做广告（笑话而已）。之后我们只见过一次，而大部分时间就在每周一次的W3C XSL-FO工作组的例行电话会议上讨论交流。

Liam自从2001年起就全职为W3C工作[2]，参加包括XML和XSL在内的很多技术标准的制定，我低头读了一下他讲座的标题“自动XML命名空间”（Automatic XML Namespaces）[3]，不由暗地思量这又是什么新的idea呢？因为一直以来，业界对XML的命名空间就颇存争议，觉得它的本意是好的，但是现实状况表明对XML的使用者和对XML应用程序的开发者来讲，命名空间的使用和实现过于复杂。Liam在开始一段的演讲中也谈及在一个XML文件中使用多个命名空间的几个主要的困难：

需要记住一些冗长的URI[4]，用户往往在拷贝、粘贴或是手工输入时发生错误，导致命名空间无法正确识别。
需要每个XML的使用者记住哪个XML的元素（Element）或属性（Attribute）属于哪个地址空间。但其实这样的记忆往往不必要。
在XSLT和XQuery的XPath处理中，花费太多时间来进行地址空间的比对，不够有效。

针对这些问题，Liam提出好的解决方案应具备以下几个条件：

无偿提供，解决方案应该是免费的
无偿实现，解决方案没有专利的束缚
使复杂的生活变简单（Makes life simpler）
易于开发者实现
与当前的万维网标准兼容
给XML的从业人员带来明显的益处

在考量了几个现有解决方案的优缺点以后，Liam最后提出了他自己的方案，即使用一个命名空间的文件来唯一标识一个元素或属性的命名空间。需要了解更对内容的读者可以在下面第三个参考文档链接中找到详细的说明。

这样的设计的确解决了现存的问题，但是我还是存有疑问：第一、这个设计和XML Schema[5]有没有重复？第二、这会不会造成一些注明命名空间的网上资源文件被过于频繁地索取，从而造成服务器的过载？有机会我会问Liam这两个问题。

网络参考文档：

http://www.w3c.de/Events/2006/PrintSymposium_en.html
http://www.holoweb.net/~liam/cv/
Quin, Liam R. E. “Automatic XML Namespaces.” Presented at Balisage: The Markup Conference 2009, Montréal, Canada, August 11 - 14, 2009. In Proceedings of Balisage: The Markup Conference 2009. Balisage Series on Markup Technologies, vol. 3 (2009). doi:10.4242/BalisageVol3.Quin01. (http://www.balisage.net/Proceedings/vol3/print/Quin01/BalisageVol3-Quin01.html)
http://labs.apache.org/webarch/uri/rfc/rfc3986.html
http://www.w3.org/XML/Schema

Balisage 2009标识技术会议（二）

sqlcrdft — Thu, 13 Aug 2009 11:37:00 GMT

第一天（8/11/2009），上午

关键词：标准，误区，项目管理，非目标（non-goal）

自美国西海岸飞行大约六个小时，我的班机终于降落在蒙特利尔机场，加拿大海关的工作人员和蔼可亲，我很快通关出机场，坐上出租去市中心的Best Western Europa酒店，那也是Balisage 2009会议所在地，据介绍这个旅店已经有八十多年的历史。会场设在这个小巧而精致的酒店的M层（就是位于一层和二层中间的Middle层）。到达时已近午夜，所以我没有多逛，径直回房休息，就等第二天会议开幕。

OK，闲话少叙，马上进入正题。会议组织者在第一天上午安排了三个报告，我觉得一个比一个精彩。

首先上台的是一位中年女学者，Ms. Tommie Usdin，演讲的题目是“被认为有害的标准”（Standards considered harmful）[1]。

有意思是她一上台就开始“抱怨”，究竟抱怨什么呢？她说，标准太多，泛滥成灾，有时候甚至变得有害了。她解释说，在项目的实施中采纳业界标准并不一定有助于项目的真正目的。项目的实施者必须注意最基本的要素：

项目的决定性人物（Stake holder）
是谁在关心什么（Who care what）
项目的目标和项目的非目标（Project goal and project non-goal）
项目目标的重要性顺序（Prioritize project goal）

Tommie着重说了第三点，特别提醒注意项目的非目标。一个项目必须使用有限的资源在有限的时间实现项目中最重要的目标，所以过度遵照一些冗长且对项目的目标无实际意义的标准，只会对项目的实施起反作用。Tommie举了个有趣的例子，一个年轻的人类学家到了一个偏僻村庄的破旧不堪的图书馆，找到一大堆有助于他新的论文的记录当地土著居民生活的日记。人类学家担心这些极有价值的文献会随这个图书馆和村庄一起消失，但他却无法说服管理员借出这些日记，所以想用计算机和标识语言数字化这些珍贵的文字，项目的目标是他自己可以查询就OK。一开始这个学者使用HTML，因为HTML最简单，看完一本薄薄的（六十四页）HTML书就可以上手，所以招几个大学生打工就可以完成项目。之后听人介绍采用了XML，又听人说要用业界统一的文档XML标准。突然一本六十四页的参考书变成了六十四本厚厚的参考书。而本来使用一些简单的PERL[2]就可以做到的HTML处理器，变成要使用“艰深”的XSLT。这个学者最终未能完成他的项目。

Tommie的讲座发人深省，作为一个实施软件项目的工程师，她所谈及的话题令我不由得去审视我所曾经和正在做的项目是否有的也不经意间陷入了盲从标准的误区。

网络参考文献：

Usdin, B. Tommie. “Standards considered harmful.” Presented at Balisage: The Markup Conference 2009, Montréal, Canada, August 11 - 14, 2009. In Proceedings of Balisage: The Markup Conference 2009. Balisage Series on Markup Technologies, vol. 3 (2009). doi:10.4242/BalisageVol3.Usdin01.
Practical Extraction and Report Language, http://en.wikipedia.org/wiki/Perl

Balisage 2009标识技术会议（一）

sqlcrdft — Wed, 12 Aug 2009 10:12:00 GMT

关键词：Balisage Conference 2009 加拿大蒙特利尔 XML

自一九九七年开始，八月的加拿大蒙特利尔一直是专业标识技术人员聚会的时间和地方[1]。今年有幸参加这个会议的我在以后几天时间里将为对XML（eXtensible Markup Language 可扩展标识语言）和其相关知识感兴趣的博客读者介绍我在蒙特利尔的所见所闻。希望大家喜欢我的系列报道，并对文章的内容多提宝贵意见。这里我首先谢谢各位的热心参与，并给心急的读者简单介绍一下“Balisage”的背景知识。

“Balisage”是蒙特利尔当地对“标识”（或英文单词“Markup”）的称谓。根据维基百科[2]的叙述，这个词缘自ISO（国际标准组织）在法语版SGML（Standard Generalized Markup Language，XML的前身）[3]中对标识的称呼。而Balisage 会议是一个标识技术的从业人员相互切磋（peer-reviewed）的盛会，它旨在提供标志技术的研究人员和开发人员一个平台将这个领域的发展潜力推向极致。这个会议讨论的话题都是围绕着标识语言的不同应用，比如怎样创建标识；怎样用标识提供含义；怎样分层和重复；怎样建模，分类，转型；怎样查询，查找和获取标识信息；怎样表示和访问；使计算机系统让标识语言“跳舞”（在更小的空间里让标识发挥更大的作用）。简而言之，使用标志改变这个世界和万维网。

“Balisage”同时也是一个XML和XSL（eXtesible Stylesheet Language）[4]的会议。同时它也包括了XSD[5]、XQuery[6]、RDF[7]、UBL[8]、SGML、LMNL[9]、XSL-FO[10]、XTM[11]、SVG[12]、MathML[13]、OWL[14]、TexMECS[15]和RNG[16]等和其他已经或尚未和这些缩写挂起钩来的技术。

让我们来看一下将在这次会议上做技术讲演人员的名单[17]，其中包括了一些在XML业界耳熟能详的名字，比如Michael Kay、Liam Qiun、C. M. Sperberg-McQueen和Norman Walsh。想必你已经迫不及待等着和我一起去八月的蒙特利尔了。OK, Buckle up, and stay tuned。

以上由微软（中国）研发集团SQL事业部XML项目组的蒋欣采编提供。

网络参考文档：

微软SQL Server中文论坛

sqlcrdft — Tue, 04 Aug 2009 11:21:00 GMT

微软SQL Server中文论坛是一个由微软官方主办的论坛，在今年一月份重新改版后，以更友好的界面，更灵活的功能出现在大家面前。SQL Server中文论坛的管理团队包括十几名优秀的微软最有价值专家（MVP），以及微软全球技术支持中心的工程师，每天都有各种SQL Server的问题在上面提问和得到解答。更为重要的，这个论坛得到了微软中国SQL Server产品组的大力支持。SQL Server产品组有七十几位工程师，每个月都会活跃在论坛上，参与讨论和回答问题。通过SQL Server的中文论坛，您可以深入学习、讨论和交流各种SQL Server技术，从而让你可以安全、高效、稳定的使用SQL Server，成为微软技术领域的专家。微软的目标是把这个论坛是建成中国国内最大的SQL Server的中文论坛，从而提供给中国的SQL Server用户的最好的讨论交流社区。论坛链接：http://social.microsoft.com/Forums/zh-CN/sqlserverzhchs/threads。

ODBC Rocks！

sqlcrdft — Thu, 16 Jul 2009 06:37:00 GMT

在发布了19年之后，ODBC已经成为软件工业的基石之一。本文将为您介绍为什么ODBC会扮演如此重要的角色，微软SQL Server和ODBC的关系，还会讨论未来ODBC的发展方向。

作为一个被广泛使用、跨平台、跨数据库的数据访问技术，ODBC已经取得了巨大的成功。ODBC可能是ISO/IEC 9075-3：2003 SQL调用级接口（Call Level Interface，全部SQL标准的第三部分）最广为人知的实现。ODBC包含在Windows、MacOS和所有主要的Linux版本中，也包含在很多Unix版本中，例如AIX、HP-UX、Solaris和FreeBSD。甚至PDA和Smartphone手机都包含ODBC！

虽然人们总是把ODBC作为C和C++程序应用接口（API），ODBC也可以在其他的编程语言环境下使用。举例来说，很多COBOL程序用ODBC来做数据访问，动态语言如PHP、Perl、Python、Ruby，还有一些快速应用开发工具（RAD）如微软Access也使用ODBC。

尽管ODBC多用于关系数据库的连接，其他数据源也很少能离得开ODBC驱动：文本文件、Excel表格，dBase、Paradox、C-ISAM、Btrieve还有VSAM等索引顺序存取方法（ISAM）数据源，你能想到的基本上都有相应的ODBC驱动程序。对于没有ODBC驱动的数据源，你很容易就能找到一个第三方的ODBC驱动，或者用驱动开发工具包来填补这个空缺。总而言之，没有一个关系数据库离得开ODBC驱动。

ODBC广泛用于企业级应用开发，大多数主流独立软件供应商（ISV）都提供对其的支持。ERP、CRM、SCM和微软office，都通过ODBC来做查询、分析、报表生成，还有ETL（数据抽取、转换和加载）。

是什么让ODBC在不同的软件业细分市场都如此流行呢？为什么ODBC在可以预见的未来还会继续流行下去？

对于数据源（Data Source）的拥有者，ODBC是必须的。ODBC同ADO.NET、JDBC和OLE DB一样，作为工业标准的应用编程接口（API），使数据源可以被程序开发者、被第三方工具和程序包访问。为所有这些数据访问技术开发相对应的驱动需要花费大量的时间、财力和物力。如果资源有限或者时间紧迫，最好的策略是什么呢？应该是先实现ODBC驱动，之后再考虑实现别的驱动。为什么？第一，其它所有的API都可以桥接到ODBC上，一旦有了ODBC驱动，你就可以通过其它任何API来访问数据库。第二，即使不考虑桥接，ODBC可以给数据源用户提供最广泛的第三方软件支持，因为ODBC是最早最成熟的数据访问技术，累计了大量的工具和应用。

ODBC能，而且通常是在专有的（proprietary）API之上实现的。在ODBC发展的早期，很多人认为这是第一代ODBC驱动的缺点。但是后来的研究表明，把ODBC建立在专有的Native （Native）API上对性能的影响微乎其微。在某些情况下，如果ODBC驱动引入策略去克服底层Native API的薄弱环节，ODBC甚至比专有API更高效。对于一些数据库来讲，包括微软SQL Server，ODBC都能满足作为专有Native API的角色。

企业IT和企业开发人员生活在一个非常多变的环境中，他们必须支持多语言、多操作系统，还有多种数据源。他们的压力一方面来自整合和标准化应用平台，另一方面来自改进现有程序，重整业务流程，提高信息整合，还有引入商业智能（Business Intelligence）。如何应付这些压力呢？

在数据集成和数据整合的情景下，从ETL到BI，ODBC的普及是很有价值的，它能将数据从数据包和客户应用中提取出来。

.Net平台现在被广泛应用于新的开发中。但在许多情况下，从时间、业务风险、整体成本因素上考量，代码重用和修改现有程序更容易被接受。在这方面，ODBC能做的很多。通常来说，应用程序开发人员通过在Visual Studio里使用/CLR编译选项，可以很容易的重新编译现有的代码，使得它能在.Net应用里被重用。这极大地简化了现有的C++和ODBC的业务逻辑与一个现代化的用户界面之间的结合，用户可以快速开发.NET平台应用。ODBC为各种不同的数据源和操作系统提供了一个通用的API，可以同步的访问多个数据源。这些是信息整合，聚集和集成的基本要求，无论是在native应用中，还是通过.Net平台的ODBC数据提供程序（Data Provider for ODBC）。

除了直接重用现有的业务逻辑，ODBC也是替换其他专有的API的一个重要候选。比如在做数据库迁移的时候，把使用如DB – Library，CT-Library或者OCI的应用程序迁移到ODBC上，要比完全用.Net重写来得高效和低成本，因为ODBC同其他Native API是很相似的。

ISV通常会支持多种不同的数据库，从而增加市场和客户吸引力。ODBC提供了多种办法来满足这一要求。总之，ODBC提供了一个通用的API，可以处理多个数据源，而且如上所述，有广泛且可用的驱动程序。当然，不同的数据源也有不同的特性，这反映在一系列不同的ODBC驱动程序上。

解决这一问题的最简单的办法是使用最严格的行为模式和SQL方言子集（SQL dialect subset）。ODBC提供转义序列（escape sequences）来解决SQL方言之间的细小分歧。如果这还不够，下一步应用程序可以通过ODBC查询驱动程序的特性、数据库的特性，动态的来处理。应用程序也可以判断出实际的驱动程序和数据库，在通用性和驱动程序特性之间权衡，从而满足严格的功能和性能要求。而且，ODBC对应用程序提交到数据源的SQL语句没有任何限制，因此不会影响SQL方言的丰富性。

一些ISV使用内部的数据抽象层来实现功能——用不同的API访问不同的数据库。即使是在这种情况下，ODBC也可以胜任。对于一些数据库，特别是微软SQL Server，ODBC是性能最好的API。

系统集成商和增值经销商（VAR，Value Added Reseller）从两方面受益于ODBC。他们可以确信，无论什么操作平台和其他基础设施，所有数据源都会有ODBC支持，从而不需要开发一个专门的工具。其次，相比于技能相对狭窄的技术人员，熟悉ODBC的技术人员可以满足更广泛的客户需求。

ODBC和微软的SQL Server

对于软件行业的方方面面来说，ODBC有广泛而持久的吸引力。虽然有时候低调了些，ODBC仍然是Microsoft数据平台一个重要的组成部分。现在，让我们讨论一下关于ODBC和Microsoft SQL Server之间关系的更多细节。

最早的时候， DB-Library是SQL Server唯一的客户端应用程序API。后来，SQL Server　API家族又添加了ODBC，然后是OLE DB，以及最近的ADO.NET。DB-Library由于技术上的限制已经不推荐使用，只是为旧的应用程序提供向后兼容性。

“在OLE DB发布后，微软的专家们相信它将取代ODBC 。现在情况已经彻底改变了... ”

在OLE DB发布的时候， SQL Server团队相信OLE DB将取代ODBC 。实际情况已经完全改变了，ODBC的未来前景十分看好。ODBC的应用比OLE DB广泛的多，和OLE DB比，ODBC更适合于一些关键的应用，我们将在本文后面一些讨论这个问题。

OLE DB和ODBC都是用于SQL Server的Native API，它们直接映射API调用到SQL Server的网络协议——TDS（Tabular Data Stream，一种表格式数据流的协议) 。ODBC是TDS之上一个非常薄的封装，在网络数据包缓冲和应用程序之间，没有额外的中间缓冲层。因此，它具有优良的性能和很好的负载能力。

支持Microsoft SQL Server的ODBC和OLE DB驱动包含于WDAC （Windows数据访问组件）中。WDAC就是原来的MDAC （ Microsoft数据访问组件）。另外，ODBC和OLE DB驱动也包含在Microsoft SQL Server Native Client（SQL Server 本地客户端）中，用来支持微软SQL Server 2005，2008和更高版本。WDAC中的ODBC和OLE DB驱动已经不推荐新的应用使用，只是为旧的应用程序提供向后兼容性。想要有更高的性能，更好的稳定性，或使用SQL Server新特性的应用程序需要使用Microsoft SQL Server Native Client。这些新特性包括快照隔离，数据库镜像，查询通知和某些数据类型（如XML和VARCHAR （max））等。微软将继续在ADO.NET （通过SqlClient）、ODBC和OLE DB （通过SQL Server Native Client）和JDBC 中添加对SQL Server新特性的支持。

ODBC未来的角色

我现在列举一些关键的应用，来说明ODBC将在SQL Server的未来中扮演的重要角色。一些SQL Server的组件内在地依赖于OLE DB，并反映在外部接口上。由于认识到ODBC的广泛普及，微软已经决定继续支持Microsoft OLE DB Provider for ODBC, 包括Windows Server 2003、 Windows Vista、Windows Server 2008、Windows 7和Windows Server 2008 R2的32位和64位版本。这保证了当用户认为ODBC是最好选择的时候，可以很容易的找到相关组件。

动态语言，如PHP、Perl、Python和Ruby，应用十分广泛。.NET平台支持其中一些动态语言，其他一些平台上也同样支持多种动态语言。虽然不同的库有着不同的质量和性能，几乎所有这些语言都可以通过ODBC访问微软SQL Server。微软将不断评估是否有必要对这些库进行基于SQL Server的优化。说到这里，微软已经发布了一个基于Microsoft SQL Server Native Client ODBC Driver的PHP扩展库。

应用迁移和服务器整合作为一种降低运营和许可费用的手段，越来越受到业界的重视。 SQL Server卓越的总拥有成本（TCO）在这一点上很有吸引力。正如上文所讲，ODBC在数据整合和应用迁移上扮演了一个重要的角色。微软SQL Server迁移助手（Migration Assistant）是一个用来帮助客户迁移架构（schema）和数据库本身到Microsoft SQL Server的工具。微软也致力于开发一些文档和工具，以帮助用户将应用程序迁移到ODBC和Transact SQL上。

非Windows客户端和mid-tier服务器在上述情况之下又增加一个额外的层面。目前第三方ODBC驱动程序已经基本满足客户的需求，但微软仍会不断评估提供自有驱动的必要性，以确保客户获得最好的体验。

最后，微软希望现有的客户将来能获得更大的成功。这涉及到将他们现有的代码通过应用程序更新和代码重用来获得最大的回报。如果现有的业务逻辑能继续满足业务需求,那么代码重用比重写一遍更有意义。例如，不管采用何种应用架构，金融应用程序都使用相同的算法来做预测分析。又例如，分析批处理和call center程序，并将其重新部署成SOA（面向服务体系结构）模式，从而使其适用于B2B和无人售货等情形，也很有商业上的意义。当然，.NET在开发新的通讯、用户界面程序方面很有竞争力，但是，基于C++和ODBC的业务逻辑和数据访问程序可以很容易的被重用，而且只需要很小的改动和很低的成本。Visual Studio和C + + CLI提供很好的重用和互用性，而且以后还会通过提供完善的重构（re-factoring）工具来继续拓展这些能力。

未来15年内，ODBC蕴藏怎样的机遇和挑战呢？

有两个重要的且相关联的问题。第一，作为最重要的native API，如何保证ODBC继续更新从而适应SQL Server的新功能？第二，ODBC如何继续扮演作为工业标准的跨平台、跨数据库API的角色？

ODBC驱动程序可以在核心ODBC规范的基础上添加驱动特有的扩展，正是有了这种可扩展性，Microsoft SQL Server Native Client添加了对Microsoft SQL Server新特性的支持。其他驱动也可以添加自己的扩展。下面的两个例子演示了Microsoft SQL Server Native Client如何支持SQL Server的新特性。

SQL Server 2008增加了额外的日期/时间数据类型，以补充现有的datetime和smalldatetime类型：date和datetime2对应于现有的SQL_TYPE_DATE和SQL_TYPE_TIMESTAMP类型；time（具有7位小数秒精度）和datetimeoffset（datetime2加上时区信息）没有相对应的ODBC数据类型，所以Microsoft SQL Server Native Client添加了新的数据类型：SQL_SS_TIME2和SQL_SS_DATETIMEOFFSET。

SQL Server中，table-valued参数（TVP）是用于T - SQL语句或存储过程中、可以由多个行和列组成的参数。例如，考虑以下声明：

Insert into OrderItems (OrdID, ProdCode, Qty)
Select ?, ProdCode, Qty from ?

第一个参数是新插入的OrdID主键，但二个参数是一个TVP参数，它包含了每个OrdID相对应的列，TVP实现了在一个SQL语句中，用一个参数，来插入多行。TVP通过减少客户端和服务器端的交互以及在TDS和关系数据库引擎上的优化，有效的改进了性能。通过加强封装性，一个单一的存储过程可以执行完整的事务处理。存储过程通常限制参数为“矩阵式”，TVP弱化了这种限制，极大的提高了代码清晰度。看下面的例子：

create type OrdItemType as table(
ProdCode integer, Qty integer)

create procedure OrderEntry
(
      @CustCode varchar(5),
      @Items OrdItemType READONLY,
      @OrdNo integer output,
      @OrdDate datetime output)
as
      set @OrdDate = GETDATE();
      insert into Orders (OrdDate, CustCode)
          values (@OrdDate, @CustCode);
      select @OrdNo = SCOPE_IDENTITY();
      insert into TVPItem (OrdNo, ProdCode, Qty)
          select @OrdNo, ProdCode, Qty from @Items
)

如果没有TVP，你需要用两个存储过程：每个数据表对应一个存储过程。

因为我们可以把TVP和传统的单值参数在一个SQL语句中混用，绑定ODBC参数时，SQL Server Native Client必须提供一种方法来处理这种嵌套表。具体是这样的：首先把TVP绑定成SQL_SS_TABLE——一个代表嵌套表的新SQL类型；然后通过SQLSetStmtAttr将SQL_SOPT_SS_PARAM_FOCUS 设置为TVP参数的序号，这表明接下来的SQLBindParameter是用来绑定该TVP中各列的（而不是“顶层“的参数）。一开始我们认为TVP这个ODBC扩展过于复杂和困难，通过上述实现，这变得十分简单，代码紧凑而且清晰可读。SQL Server中完整的TVP实现建立在已有的ODBC规范——array binding和“data at execution“之上。这允许TVP中的各行数据可以在运行时提供，这些数据既可以是内存中的数组，也可以是分批地传到服务器的一行或者多行数据。

到目前为止，一切都很顺利。 SQL Server Native Client的实践表明，一个ODBC驱动程序可以添加一些重要功能，而无需更改ODBC规范。但是如果一个SQL Server新的功能超出ODBC的扩展能力怎么办？ODBC的结构是否会在新的SQL Server应用下显得捉襟见肘？这些都是棘手的问题，其中可能的解决办法包括：更新ODBC核心规范，或者将SQL Server Native Client变成一个Native API ，可以从ODBC驱动程序管理器（ODBC Driver Manager）上剥离，从而不再受到ODBC规范的限制。这两个办法都影响深远。

改变ODBC规范并非完全无风险。ODBC最大的优点之一是它的稳定性。改变ODBC规范和现有的驱动程序，可能会让应用程序产生新的不确定的行为。如果从当前的规范中分离出来，能满足某些应用但是可能会破坏其它更多的应用。对于ODBC和SQL Server Native Client来说，有没有一个乌托邦式的“第三种选择”呢？IBM　DB2的调用级接口（Call Level Interface）可以运行在两种模式下：作为ODBC 驱动（通过驱动管理器Driver Manager）或者独立的call level interface. 对于SQL Server Native Client和ODBC来说，这可能是一个渐进的过程。另一个选择是，让现有的和将来的ODBC版本并存。目前，ODBC驱动程序管理器已经做到ODBC2和ODBC3的并存。

有没有其他组织对扩展ODBC现有规范感兴趣呢？在这方面，微软要鼓励有关方之间的讨论，评估某些广泛共识的可行性。而某些社区形式为基础的创新，比起ISO或ANSI，可能反应更快速，投入更广泛。不过有一点可以肯定，不管发生什么，没有什么可以破坏ODBC丰富的遗产和其持久的产业价值。

微软把实体数据模型（Entity Data Model，EDM）视为一个改变整个软件产业的革命性技术，在现有的ADO.NET实体框架（Entity Framework）上得到了很好的应用。想象一下，如果把ODBC和EDM结合起来，将是多么的激动人心。ODBC可以来支持实体SQL（Entity SQL）上的查询，返回有多行和嵌套实体值的实体结果。TVP中处理非矩阵性数据的经验表明在SQL Server Native Client上对EDM做驱动层面上的扩展是完全可行的。另外，除了SQL Server，微软正在引入越来越多的数据源来支持EDM，其他的一些关系数据库产品也可以通过ADO.NET Entity Framework来支持EDM。所以为什么我们不能直接在ODBC的核心规范层面上来支持EDM呢？答案在一定程度上取决于ODBC应用程序在哪个层面上使用EDM：EDM和关系型访问分别在不同的驱动上？同一个驱动的不同连接上？还是在同一个连接上？是渐进的将EDM应用到现有的代码里，还是只在新的代码里使用？这是另一个微软希望能听到有关各方讨论的领域。

ODBC已经走过了漫长的道路，希望这篇文章能给你带来对ODBC一些新的理解：ODBC有哪些已经存在了很久而且还将一直为你所用的功能；它今后会如何发展；微软保证将长期提供对ODBC的改进和支持。

如果你想就本文中所提及的内容做进一步的讨论，请发送电子邮件至odbcfut@microsoft.com 。

你可以在以下链接找到更多关于ODBC的信息：

ODBC Rocks！英文原文

http://www.code-magazine.com/Article.aspx?quickid=0712172
Mike Pizzo：微软数据访问APIs 的历史
http://blogs.msdn.com/data/archive/2006/12/05/data-access-api-of-the-day-part-i.aspx
Wikipedia ODBC
http://en.wikipedia.org/wiki/Open_Database_Connectivity
Ken North：SQL and ODBC in integration frameworks for Business Integration Journal
http://www.sqlsummit.com/PDF/BIJ_North_Nov2004.pdf
Ken North：ODBC portal
http://www.sqlsummit.com/ODBCPORT.HTM
ODBC MSDN文档
http://msdn2.microsoft.com/en-us/library/ms710252.aspx
Microsoft SQL Server Native Client MSDN文档
http://msdn2.microsoft.com/en-us/data/aa937705.aspx
SQL Native Client 博客
http://blogs.msdn.com/sqlnativeclient/
MSDN DATA 博客
http://blogs.msdn.com/data/
SQL Server Data Access论坛
http://social.msdn.microsoft.com/forums/en-us/sqldataaccess
SQL Server 中文论坛
http://social.msdn.microsoft.com/forums/zh-CN/sqlserverzhchs/

软件测试工程师
于凯