【IT168技术访谈】
     随着SQL Server Everywhere的CTP版本在今年微软的techEd上发布，Scott Swigart将带领我们一起跟SQL Server 组的高级产品经理Mark Jewett，计划经理兼技术带头人Steve Lasker一起，来谈谈微软的这种新的数据库引擎。从中我们可以看到微软的移动数据库战略。

DDJ：微软即将要推出SQL Server Everywhere版本。它究竟是什么？为什么我们还需要另一种数据库呢？
MJ: SQL Server Everywhere版本简单来说，是为客户环境和客户应用程序设计的一种数据库。首先，它只有大约1.5 MB大小并且当你拿它和其他SQL Server产品相比时，它只是一个非常小的产品，这也使得它容易下载。第二，它在处理器中运行。应用程序的最终用户甚至不需要知道存在一个数据库。它在应用程序中无缝运转。第三，开发者现在所了解的关于SQL Server的任何事情都是可应用的知识；换句话说，如果你现在使用SQL Server那就可以应用你所熟悉的T-SQL和对象。这些类似的东西在SQL Server Everywhere版本中还有很多。

SL:对于SQL Server Everywhere，当我们开始公开我们正在做的事情时，人们说，“哦，太棒了，那正是我想要的，”然后下一个问题经常就会是，“我怎样同步数据存储呢？”人人都想要一个大的数据库来存储所有的东西，但那是不可能的。很多公司甚至都不能把他们的电话号码清单合并到一块，更不用说合并所有的数据了。一旦你接受在一个组织里面将会有很多数据库这样一个现实，问题就是，你怎么才能让那些不同的数据孤岛互相通信？这就回到我们正在实现的同步策略上（针对SQL Server Everywhere版本的）。

DDJ:有一些应用程序永远不会跟SQL Server同步，但是也有很多应用程序想要脱机同步工作，或者仅仅为了取得更好的性能想要高速缓存本地数据。SQL Server Everywhere版本有哪些特征来支持这些特定的情况呢？

 SL:当使用SQL Server Everywhere版本时，关键是拥有SQL Server产品特征的真子集。从一开始，它就使用了T-SQL语言的子集。开发者可能需要用到的技术正在以指数速率递增。我们用到的微软内部的技术数量正在以指数递增。开发者不可能用15种方式去完成一件任务。但是，如果开始时能够在客户端使用同样的技能，然后转到服务器端，那就会使开发者颇有成效。这正是SQL Server Everywhere版本值得炫耀之处。它使用T-SQL语法和ADO.NET编程模型。它是SQL Server特征集的一个子集。

   现在，当数据分布在各个字段中，你怎样把它传到中央存储区？如果数据在中央存储区，你又怎样把它分散到各个字段中？我们怎么才能使这种转换变得容易？部分答案就是SQL Server Everywhere Edition具有SQL Server数据类型的子集。所以我们不存在像使用Jet或其他本地数据库时的数据转换问题。例如，我们有nchar和nvarchar类型。SQL Server有类似XML的数据类型，SQL Server Everywhere Edition还不支持这种数据类型，这种情况下，我们把它转换成NTEXT。我们并没有丢失任何数据，只是在SQL Server Everywhere Edition中丧失了像SQL Server 2005具有的XQuery功能。

  一旦我们实现了3.1版本中的技术，我们的3.5版本就会基于这种技术并会有一个新的同步组件集。这种同步组件虽然能让你和其他数据库同步，但是它在SQL Server中会表现得更好。 你将能够基于现有的ADO.NET知识，再用用于同步的组件模型来拓展它。我们称它为“同步框架”。如果你了解ADO.NET数据适配器，我们将提供同步适配器，它会让你在服务器端和客户端把同步设施组合到一起。

本地数据存储
DDJ:假如某人正在致力于像“Microsoft Money（微软货币）”的某种开发，它不必和任何中央服务器同步。除了备份以外你什么都不用做。在本地数据存储方面，是什么东西使得SQL Server Everywhere Edition可以挑选的优秀的数据库引擎呢？

SL:还有几个值得考虑的问题。第一个问题就是，“我需要什么功能？”如果我关心的全部功能就是本地数据存储，并不需要同步像产品目录这样的东西，那么你可能会看着引擎并且问道，“它是否太小了？我能把它放到我的应用程序中吗？”在很多情况下应用程序是重点，而非你选择的用于存储的数据库。你可能还会问，“它是否影响到我的整个应用程序的安装或运行时体验呢？” SQL Server Everywhere版本小而轻，使用过程存储,所以非常适合。一旦你想了解更多，就不得不看它的核心特征。例如，“这个引擎有查询处理机吗？”当然有了。“它能够处理其他的装载吗？”当你只有10个应用，你或许还能使用XML或者文本文件，但是一旦达到成百上千个以后，你就会遇到以前从来没有的问题。查询处理机在两个方面有助于问题的解决。首先，它以非常高效的方式让你得到数据子集。其次，你怎样把你正查询的信息装到内存中？若用XML，你可以查询XML文件来获取特定元素，但是经常你得把整个XML文件装到内存中以完成查询。

事务也变得相当重要。比方说我想要做一次更新，删除或者插入。如果因为掉电，丢失设备或者违反商业规则而失败了，我怎样确保它们以要么全有要么全无的方式被提交？在很多地方，人们说如果你仅仅给他们一个查询处理机和事务，那就是他们需要的全部了。

有几个产品当前发展受阻。那么，你需要静下心来看一看今后两三年的发展道路，看一看微软将会在哪些地方投资。随着一些新的方案变得重要，例如XML作为数据库数据类型，或者新的硬件体系结构的演进，你需要问这个数据库引擎是否能够继续发展。例如，引擎能否顺畅地在64位机上运行？长远来看你需要关注微软的战略投资。微软公开说，SQL Server Everywhere Edition是一项非常重要的战略投资。从工具角度来讲，Visual Studio将会做大量工作以确保SQL Server Everywhere Edition成为开发人员开发经历中第一位的焦点。

DDJ:你刚才提到你们将在Visual Studio "Orcas"之前发布3.1版本，和Orcas同时发布3.5版本。你也提到，虽然它被称作SQL Server Everywhere Edition，实际上并没有“server”需要安装，只是几个动态链接库。所以我认为在将来，一个应用程序可能正运行在3.1版本上，你可能还会在使用SQL Server Everywhere Edition 3.5版本的同一台机器上添加一个新的应用程序，这两个数据库引擎能够并行运行。我说的对吗？

SL:那是我们正在努力实现的一个基本原则。如果我有应用程序1已经安装并且正在工作，同时我又安装应用程序2，我想要保证应用程序1不会被中断。那么我们必然要支持SQL Server Everywhere Edition的并行安装。对于这一点有赞成观点也有反对观点，但是对于大部分客户来说，他们赞成并行。如果应用程序1正在3.1版本上运行，而3.5版本又推出了，应用程序1继续在3.1版本上运行直到应用程序1的开发组决定将它移到3.5版本上。

安全性
DDJ:谈一下引擎本身的维护问题吧。如果引擎存在bug或者安全隐患，怎样获取补丁呢？

SL:在3.1版本中我们将支持两种配置模型。第一种，如果你使用MSI完成传统的安装，SQL Server Everywhere Edition在每台机器上就安装一次。在这种情况下SQL Server Everywhere Edition从Microsoft Update中直接得到服务，Microsoft Update是一个用户可选的服务模型。使用这种模型的挑战性在于，它需要管理权限来把SQL Server Everywhere Edition安装到机器上。SQL Server Everywhere Edition产品由本地和被管理组件组成。本地组件不需要管理权限安装。它们能够从“文件和设置”文件夹中打开。在这种模型里，SQL Server Everywhere Edition简单地用作动态链接库和应用程序绑定到一块，Windows Update不会更新SQL Server Everywhere Edition。应用软件的厂家还必须维护他们程序中的那些动态链接库。许多应用软件厂家经常告诉我们他们不希望微软来维护这些部件。他们希望当有一个可安装的组件时，安装上那个组件测试一下他们的应用程序，然后用SQL Server Everywhere Edition的组件去配置他们应用程序的一个新版本。

我们在3.1版本中实现了这些功能：你可以进入一个Windows Forms项目，添加一个SQL Server Everywhere Edition的引用，把SQL Server Everywhere Edition DLLs拷贝到应用项目中，并且有ClickOnce配置工具替你把所有东西都配置好。当你用这种方式配置一个应用程序时，你将会在“添加/删除程序”中看到你的程序，但是你看不到SQL Server Everywhere Edition。

有关.NET框架是如何工作的有一个原始工具，它在安全性方面有趣的是，当汇编程序装载器装载汇编程序时，它总是首先查看全局程序集高速缓存（GAC）。如果它在GAC中找不到那个程序集，那么它就会在应用程序目录中查找。如果公司里的SQL Server Everywhere Edition存在一个关键的服务问题，他们又不确定哪台机器安装了SQL Server Everywhere Edition，因为应用程序已经悄悄地和SQL Server Everywhere Edition绑定到一起了，他们则能够使用MSI安装将SQL Server Everywhere Edition找到，这种新版本将会超越个人应用版。

在和我们过去产品的历史对比中，讨论一下安全和风险问题也是很有趣的。如果你看一下SQL Server Everywhere Edition的表层区域，我们传统上有问题的地方正是一个产品特征成为安全陷阱的地方。SQL Server Everywhere 版本，因为它不作为服务运行，所以不监听网路通信量。事实上，它不能监听网路通信量。表层区域和我们的SKUs服务器，包括SQL Server Express 版本，有天壤之别。SQL Express确实会错误地将网络切断，但是它还能接上，所以它是作为服务来运行的。这些特征可以受保护，但是它们仍然存在。使用SQL Server Everywhere版本受攻击的可能性会更少。

另一个安全方面的考虑是运行在数据库内部的代码。许多数据库允许你把代码嵌入到数据库里面。但是因为SQL Server Everywhere Edition在你的应用程序中使用处理器，它和你的代码一起在处理器中，所以你为何要在在数据库中运行代码呢。在SQL Server Everywhere版本中，你不能把代码放到数据库里。这也减少了受攻击的可能性。它不存在像SQL Server的xpCommandshell（xp命令内核）的东西。用户根本不可能脱离数据库而在应用程序范围之外做一些事情。

DDJ:那么它和Access相比的话，Access数据库中可以包含宏，因此用e-mail到处发送是不安全的，一个SQL Server Everywhere Edition的数据库用e-mail发送给某人则是安全的，因为它仅仅是数据。里面没有可运行的东西。

SL:完全正确。过去某段时期在数据库文件里不存在代码。在Access和SQL Express中，数据库文件可以包含代码，但是在SQL Server Everywhere Edition中又不能了。

DDJ:内存数据库引擎存在的一个问题是数据文件可能会损坏，需要修复并且需要压缩。SQL Server Everywhere Edition中也存在这样的情况吗？它是内存数据库吗？

SL:你要想一下SQL Server Everywhere Edition的起源。它起源于设备。设备若是关闭了，或者它们的电池没电了，你可以将它们搁置或者切断。SQL Server Everywhere Edition始终是为那种环境设计的，颇具可靠性。但是，当然了，任何事物都有瘫痪的可能性。我不会说决不可能。有趣的是，当问题真的发生了，你怎么着手解决它们？若是使用SQL Server，你需要解雇SQL Server管理者，让DBA介入，然而使用SQL Server Everywhere Edition有一种简单的API来实施这些操作。这是SQL Server Everywhere Edition另外一个备受开发者关注的地方。这种逻辑编码到你的应用程序中很容易。有一种叫做SqlCeEngine的组件，它具有一些这方面的API恰好提供你正谈论的那些功能子集。有了这些API，当你修复时，你可以试着选择修复故障发生时正在处理的任何一个事务，或者，如果你无法修复它们，则可以清除那些事务。

DDJ:那么人们怎样才能使用到SQL Server Everywhere Edition呢？

MJ:目前可以得到它的预览版(CTP)。你可以登录www.microsoft.com/sql/everywhere，更多地了解有关SQL Server Everywhere Edition的信息，可以下载部件，评价它并且在上面做开发。发布日期将会在今年的年末。

DDJ:感谢您能抽出时间来和我们聊天。

    －－－－－－－转载请与责编联系－－－－－－