SQL Server 2005 Express Edition 是 Microsoft SQL Server 的 Microsoft 桌面引擎 (MSDE) 版本的替代产品。它的体系结构完全重新设计，您可以像使用 Microsoft Access/JET 数据库那样安装和使用它，但是不会出现与该方法相关联的问题。SQL Server 2005 Express Edition 为满足下列应用程序的需要而构建更好的解决方案，这经历了很长的历程：
• 替代 JET 数据库。也就是说，如果需要，可以由 IT 部门代替 DBMS，这一方面可以满足 HIPA 安全性的需要，一方面可以使用所有 SQL Server 保护数据和参照安全性的功能，并且无需考虑用户采取的手段。（HIPPA 或 HIPAA（通常简略为 HIPA）指联邦立法部门，该部门要求将可靠的安全性和访问保护用于存储个人医疗卫生信息的数据库中。）
• 无需升级到 SQL Server Standard Edition，DBMS 即可从单个用户扩展到很多用户，并且 DBMS 无需担心在最需要调控器时，调控器的性能降低。
• 可以轻松地在小型网站上和客户端/服务器配置中工作的 DBMS。
• 当 Service Pack 可用时，可以轻松地安装并就地更新的 DBMS 引擎。这意味着安装例程可以轻松地集成到应用程序的部署脚本中。
• 通过简单地指向安装或传递到应用程序中的 DBMS 文件，就可以对其进行访问的 DBMS。因为 SQL Server Express 旨在允许数据库随时连接，它可以比以前更加简单地使用“松散”的 SQL Server MDF 数据库文件并利用应用程序对它们进行部署。这使得部署独立的 SQL Server Express 数据库 .MDF 文件非常简单，就像利用 JET 数据库完成那样。
• 引用 SQL Server 的共享实例的标准方法。当安装 SSE 时，默认情况下安装为具有相同的实例名称 SQLEXPRESS。这意味着如果假设应用程序安装例程利用了该功能，无论应用程序的连接字符串是安装在本地系统上还是安装在局域网上，它都可以更简单地针对 SQL Server Express。我会在稍后谈论实例问题。
我的新书，Hitchhiker''s Guide to Visual Studio and SQL Server 2005 (Addison Wesley)，将会用一整节来讨论 SQL Server 2005 Express Edition，但对于本文，我将重点限制在使用 SQL Server 2005 Express Edition Beta 2 的托管安全性上。随后我将会讨论下列内容：
• 什么是“安全”的系统？对于小型系统而言，安全性意味着什么呢？
• MSDE 开发人员面临着什么问题？
• SQL Server Express 如何解决这些问题？
• 应用程序如何获得对 SQL Server Express 数据库的访问？
• 如何保护 SQL Server Express 数据库？
注 在撰写本文时，SQL Server 2005 Express Beta 2 不应该用于产品系统中，不应该公开在 Web 上或在 EULA 限制外使用。
什么是“安全”的系统？
在我们深入讨论 SQL Server 2005 Express Edition 的技术优点以及如何配置其安全功能之前，我认为有必要定义安全性的实际含义。当然，对于小型企业或部门系统来说，当数据服务器受到安全威胁或其数据丢失或损坏时，该公司与大型公司一样容易面临失败。SQL Server Express 可以驻留在 Web 服务器上，为 ASP 应用程序提供 SQL Server 服务。因此，正常运行时间、可靠性和安全性也意味着对 Web 服务器应用程序公开信息的能力，但同时还不易受到来自 Web 的攻击。对于将编写代码和构建应用程序作为兼职的“经验不足的开发人员”来说，SQL Server Express 也是非常理想的。这些医生、律师、接待员和出租车司机都需要一个用于存储和检索数据的简单、安全、稳定的方式，而不必考虑在后台正在为他们所做的操作。
安全性还包括应用程序设计程序和开发人员要防止数据丢失而采取的这些步骤，无论丢失是由于意外、疏漏或是恶意攻击所致。安全性意味着将那些不应该访问数据的人员拒之门外，并保护物理文件和系统本身。它意味着制作备份并能够无缝地执行还原。利用 SQL Server Express 系统，尤其具有挑战性，因为与通常不同，没有专职系统管理员或 IT 部门介入并执行周期性的备份，或者当系统发生故障时从各个部分中进行还原整个系统。具有安全的系统意味着当发生问题时保持您的工作（并且可能会有提升），然后可以快速、安静、高效地恢复应用程序。我将会指出很多事项，您可以完成它们使应用程序更持久、更不容易受到攻击并且更易于维护。
问题是什么？
相当长时间以来，我一直都在赞美 SQL Server 的 MSDE 版本。这是因为我确信对于需要“少量用户”数据存储区的应用程序，或应用程序不需要对远程 DBMS 引擎进行访问的情况下，MSDE 是非常好的解决方案。尽管 MSDE 已经广泛地被大量关键业务采用，它们通常必须依赖自己来处理很多问题 — 实现非标准解决方案，该解决方案有时与解决相同或不同问题的其他公司的尝试相冲突。这些冲突包括：
部署：如果将 SQL Server 与应用程序一起安装将会怎样？下面就是对相关问题的阐述。例如，如果 SQL Server 已经安装，又该如何呢？如果实例名与其他现有实例冲突，又该如何呢？应用程序应该共享一个现有的 SQL Server 实例还是创建一个独特的实例呢？当卸载安装有共享 SQL Server 实例的应用程序行时会发生什么情况？它还会卸载 SQL Server 实例吗？如果会，那么该实例宿主的其他数据库会发生什么情况呢？
安全性：如果选择共享一个 SQL Server 实例，应该为 SA 使用什么密码呢？如何设置用户帐户？应用程序是否应该只是使用由域控制器管理的集成安全性呢？如果没有 Active Directory，又该如何呢？如何将数据库安装在目标 MSDE 服务器上？安装后，数据库是否对服务器上的其他应用程序可见呢？应用程序如何隐藏专用数据呢？
性能： MSDE 使用限制服务器上并发操作数量的调控器。如果单个用户应用程序需要同时执行几个操作，但是调控器不发挥作用并使其速度下降，又该如何呢？坦白地说，我不确认这个问题是十分普遍的。我曾经听到非常少的人抱怨调控器终止，并且使他们的应用程序运行得非常慢。的确，我曾听说应用程序运行得不是特别快，但是这（通常）是由于野蛮强制查询或“置疑的”数据库实现导致的结果。
可伸缩性： MSDE 数据库限制在 2GB。如果您需要比这更多的数据，又该如何呢？这是否意味着您必须升级目标系统以使用 SQL Server Standard Edition，而这可能比期望使用它的系统花费更多？另外，我所听到的最多的抱怨就是人们存储二进制大对象 (BLOB)（例如数据库中的文档或图片）时涉及的问题。一旦它们将 BLOB 替换为一个到 BLOB 文件的路径，它们的数据库就缩小到非常合理的大小了。
工具： SQL Server 的 MSDE 版本是“部署”配置。同样，它并不包括管理服务器或它所管理的数据库所需要的任何工具。我通常会推荐开发人员购买 49 美元的 (SRP) Developer Edition，它包括用于管理其 MSDE 数据库的整套工具。但是，由于许可限制，这些工具无法利用应用程序进行部署。这意味着开发人员必须构建他们自己的客户端工具或简单地将需要的功能构建到他们已部署的应用程序中。
管理： 无论它是如何完成的，应用程序必须要承担很多管理性责任。对于没有“SA”（系统管理员）值守的 SQL Server Express 系统而言，这一点尤为重要。这些管理责任包括管理登录帐户、权限、备份、还原和日志维护。最终用户通常不具有执行这些操作的能力并且不应该被信任来执行这些操作 — 这取决于应用程序。因为 JET 数据库需要周期性的压缩或修复，MSDE（和任意 SQL Server 数据库）需要周期性地备份（和转储）日志和数据库。当数据库没有进行集中管理时（集中管理可以更简单地管理管理性和维护任务），这个问题就变得相当重要。同样，这取决于应用程序。
Service Pack： 由于 MSDE 通常嵌入到应用程序中，用户可能不知道他们已经安装了一个 SQL Server 实例。同样，他们也没有注意到他们可能需要应用 SQL Server Service Pack 来保护他们的数据和系统以免受攻击，即使他们在 5 点钟新闻时看到它时，还在正常运转。为了防止由蠕虫和其他攻击病毒引起的某些问题，MSDE SP3(a) 禁用了网络连接，因此应用程序无法通过 Intranet（或 Internet）连接到服务器。问题在于 Service Pack 未能应用到很多系统中，因为用户不知道它是必要的，或者不知道如何应用修补程序。将 SQL Server 更新应用到 MSDE 安装这个问题仍然难以解决，因为 Microsoft 升级不是始终可以与用于部署 MSDE 应用程序和数据库的自定义安装脚本一起使用的。
SQL Server Express 如何解决这些问题？
近年来，世界范围的开发人员、架构师和 IT 经理一直对上述问题进行着讨论。尽管没有对所有这些问题的解决方案，但是通过一些相当基本的改动，SQL Server Express 已经解决了其中的很多问题。在了解差异之前，知道什么内容没有变化非常重要。SQL Server 2005 Express Edition 仍然是免费的（具有惯例的 licensing and use restrictions），它仍然支持订阅者复制以及实际上与 MSDE 相同的所有功能。新的 SQL Server Express 版本无法宿主报告服务，但它可以作为宿主在 SQL Server 2000 Standard Edition 上的服务器的数据源。（有关 SQL Server 报告服务的详细信息，请参阅 Boost.net 网站。）默认情况下，安装程序仍然禁用将 SQL Server Express 实例公开到网络的能力（首次在 MSDE SP3 中实现）。让我们更仔细地考察一下 SQL Server Express 是如何解决每个问题的。
部署
SQL Server Express 设计为可以通过 Web 下载，并可以像任何其他系统软件那样安装在用户系统上。（这假设系统管理员安装了 SQL Server Express。）您可以使用交互式安装程序（我将在稍后进行说明），或运行命令行安装可执行文件。利用“安静”模式，用户根本不需看到任何 SQL Server Express 安装对话框。
当安装 SQL Server Express 时，默认情况下安装程序会尝试创建一个公用的 SQLEXPRESS 实例。如果它已经准备就绪，将提示您选择放弃安装或是选择另一个实例名。此处的思想在于让使用 SQL Server Express 的应用程序共享一个公用实例，而不是创建它们自己的实例。这使得应用程序配置更加简单，同时还可以降低用户系统上的内存和磁盘占用空间。
如果卸载应用程序，最好还是卸载您所安装的任意唯一的 SQL Server Express 实例。但是，Microsoft 建议保留所有就绪的 SQLEXPRESS 实例，除非您确认系统没有任何其他使用该实例的相关应用程序。确定这一点的一种方法是搜索其他应用程序可能连接或创建的其他数据库的 Master 数据库。
安全性
默认情况下，SQL Server Express 配置为保护您的数据。在安装时，您会有机会根据要求进一步加强安全性或放松安全性。您必须首先做出的决定就是选择安装实用工具配置 SQL Server Express 实例的方式。实例就是程序的一个副本。从 SQL Server 2000 版本开始，SQL Server 允许您安装服务器的几个独立的实例。每个实例都被视为独立的实体：每个实例具有其自己的 Master 数据库、其自己的安全性配置以及其自己的磁盘和内存中的位置。安装 SQL Server Express 后，每个应用程序（或您）必须决定它是否与使用该服务器的共享实例的其他应用程序共存，或者它是否要求其自己的独立实例。有几个与每个配置相关联的安全性问题，我将在下面进行阐述。请注意，SQL Server Express 允许您安装多达 15 个实例，但是我希望人们不要安装多个实例，除非在非常特殊的情况下。
安装公用实例
默认情况下，SQL Server Express 假设您要创建（或使用）一个名为“SQLEXPRESS”的公用实例。还可以命名一个“公用”实例，但是这假设您所安装的所有程序都可以分辩出这个独特的名称。如果保留默认名称 (SQLEXPRESS)，其他应用程序可以自动共享这个公用实例。利用这种方法，所有数据库都可以由一个单个的、共享 Master 数据库管理，并且有一个永远不需要显示的 SA 密码。当使用公用实例时，您有可能看到其他安装的数据库，而其他应用程序也可能会看到您的数据库 — 除非您确保应用了适当的权限。一般而言，对于家庭、个人或小型办公室实现，您通常不必担心一个应用程序会扰乱另一个数据库中的数据。如果您安装一个单独的公用实例，那么只有一组 SQL Server DLL、缓存和其他驻留内存的结构会加载到内存中。这意味着只有一个 SQL Server 实例占用 CPU 资源。
安装独立的实例
在安装过程中，如果您将实例名设置为自己的值，那么安装程序会创建一个完全独立的 SQL Server Express 版本。该实例具有其自己的 Master 数据库、其自己的文件、DLL、内存占有空间以及其自己的 SA 密码。除了可能已安装的任意其他实例外，每个独立的实例都会启动占用 CPU 周期的单独的 SQL Server 服务（程序）。尽管该方法在某种意义上增加了安全性，只有那些被授予对该实例访问权限的程序才能看到它所管理的数据库，但是实现和维护却增加了很多成本。这是因为每个实例都要复制 DLL、缓存和其他内存中的结构。
安装默认实例
另一种方法就是在安装过程中删除实例名。在这种情况下，SQL Server Express 作为默认实例安装，假设没有已安装的默认实例。在这种方式中，只可以安装一个服务器实例。同样，如果这是安装到系统上的唯一的实例，那么在其他配置之间差异就会非常小，除非当它连接 SQL Server Express 时，我将在稍后对此进行讨论。
选择系统管理员的密码
SA 密码是解开整个数据库的密钥。系统管理员获准对数据库或数据库中的信息进行任何操作。SA 可以添加、更改或删除数据库，所有操作都可以在任何人不知道所做更改的情况下进行。正确设置这个密码并对其进行保护是至关重要的。
当您使用公用实例安装 SQL Server Express 时，只有一个 SA 密码需要关注。由于只有在您选择使用 Windows 身份验证进行安装时，SA 帐户才可以访问，所以 SA 密码永远不需要显示。在任何情况下，当安装 SQL Server Express 时，都要求您提供 SA 密码，但是在已发布的版本中，可以设置为随机（隐藏）的值。
Microsoft 建议您配置 SQL Server Express 实例以使用 Windows 集成安全性身份验证。这意味着计算机和 Windows 域系统管理员帐户都被授予对 SQL Server Express 实例的完全 SA 访问权限。当然，您需要成为计算机或域管理员才能执行维护、安装数据库以及执行像更改数据库表值这样的简单操作。这并不意味着使用 SQL Server Express 的每个人都应该成为管理员。它真正的意义在于，作为安装制度的组成部分，您需要创建“用户”或应用程序登录，并在应用程序需要的表格、视图、函数以及存储过程上设置适当的权限。我将会在稍后对此进行更详细的讨论。
性能
SQL Server Express 已经摒弃了“调控器”的概念。坦白地讲，我以前几乎没有看到调控器降低任何 MSDE 系统的情况，但是通过放弃调控器，Microsoft 消除了有关 SQL Server 引擎可伸缩性的混淆。SQL Server Express 有很多方法来限制可伸缩性。正如在测试版中所配置的那样，SQL Server Express 只能处理缓冲池中 1GB 的系统 RAM。这限制了 RAM 缓存中数据页面和过程的数量。任何 SQL Server 专业人士都可以告诉您改进性能的最简单方法就是向缓存中增加内存。将可见 RAM 限制在 1GB 意味着在您向 SQL Server Express 实例中增加负载时，您将（最终）耗尽性能。这是否意味着 SQL Server Express 可以支持 1000 个用户呢？当然，如果将负载放在 SQL Server Express 实例上并不会那么完美。在相同的情况下，10 个用户就可以将 SQL Server Express 陷入困境，尤其是如果应用程序编写得并不是非常有效时。
SQL Server Express 也限制到一个单个的处理器，而不可以在附加处理器（最多两个）上运行线程（如果系统支持）。这种限制也压缩了您期望从 SQL Server Express 获得的性能上限。
当使用 SQL Server Express 的应用程序结束时，SQL Server 并不会关闭。在 SQL Server Express 版本中并没有自动关闭选项。因此，即使在您的应用程序结束后，SQL Server 引擎也会保留在内存中，并继续占用系统 RAM 和 CPU 资源。可以编写 SQL 管理对象 (SMO) 例程来关闭 SQL Server Express 实例，但只有在您确认该实例没有被其他应用程序共享时，才可以完成该操作。
可伸缩性
尽管 MSDE 数据库限制在 2GB，SQL Server Express 数据库文件却限制在 4GB。这意味着可以比以前多存储一倍的数据。坦白地讲，这使我很困惑。我曾经在大型机上使用过大型的公司数据库，它在单个 40MB 磁盘包上非常适合。我猜想人们喜欢使用数据库来存储其宠物的大量文档和图片。对于 MSDE 而言，日志文件大小并不受限制 — 至少表面上看是这样。您仍然需要周期性地备份或截断日志，我将在稍后进行讨论。
工具
Microsoft 同时还更改了其对工具的访问方法。即使您不将新的 GUI 安装程序计算在内，当您下载 SQL Server Express Beta 2 时，新的 OSQL 版本、SQL 计算机管理器（MMC 管理单元）以及 SQLCMD 命令行工具都包括在其中，以协助管理 SQL Server Express 实例。此外，Microsoft 计划设计一个新的 GUI 工具（暂时命名为 SQL Express Manager），以执行 SQL Server 数据库的初始配置和周期性维护。这个工具很快可用于独立下载，基本上可以说，它是不同于 SQL 查询分析器的工具，可以执行用户帐户设置和维护以及协助编写、测试和调试 SQL 查询。您不能使用其他任何工具连接到 SQL Server Express，包括 Management Studio 或 SQL 企业管理器。但是，我希望在它发布前，当前的任何工具都可以访问 SQL Server Express。
管理
要管理 MSDE，您只须对 SQL Server Express 进行操作，这与对 SQL Server 的其他版本所做操作相同。我希望看到一个可以周期性地转储数据库和日志然后截断日志的自动日志备份脚本。或许，这就是企业第三方需要创建的脚本。到那时，我建议开发人员将这些管理任务构建到他们的应用程序中，然后使用 SMO 来执行这些需要的维护功能，并且使用 Windows 计划程序来进行协助。
Service Pack
SQL Server Express 只能使用 Windows Installer (MSI) 安装软件包文件进行安装。与 MSDE 不同，您将无法创建自定义的 MSM 安装脚本。在其他方面中，它与 MSDE 相同，因此您仍然需要准备通过传统的 Service Pack 方式来更新 SQL Server 引擎。在 Microsoft 工作的人都敏锐地意识到与此相关的问题，并且仍然在规划着更好的策略。
安装 SQL Server Express Edition
与 MSDE 不同，MSDE 不支持任何形式的 GUI 安装实用工具，而 SQL Server Express 允许命令行安装和 GUI 版本。对于使用标准版版本或更高版本的开发人员来说，这个安装版本是非常熟悉的。但是，在该过程的早期，SQL Server Express GUI 安装程序出现对话框（如图 1 所示），询问用户是否要设置 Advanced Configuration 选项。默认情况下，安装程序会配置正在进行安装的 SQL Server Express 实例来使用集成安全性，同时禁用对 TCP 端口和外部协议的所有访问。这意味着您将无法从其他系统或使用 SQL Server 凭据来访问 SQL Server Express 实例，除非更改高级配置选项。
 |
选择安全性模式
SQL Server Express 安装实用工具允许您在身份验证模式对话框（如图 2 所示）中设置服务器所使用的安全性类型。正如我将在稍后讨论的那样，默认模式是 Windows Authentication，它会根据域 Active Directory 数据库来验证用户凭据。在理解切换到 SQL Server Mixed Mode 安全性的安全意义之前，最好保留为默认模式。例如，混合模式 (SQL Server) 安全性强制开发人员指出隐藏由其应用程序所使用的 SQL Server 凭据的方法，以防止肆无忌惮的黑客的使用。尽管如此，最好还是坚持使用默认设置，除非您的设计使该配置无法使用。
兴趣使然 黑客从何处来？在伦敦举行的 Diligence Information Security 研讨会上，一项调查表明大多数“黑客”（那些试图获得对受保护的数据进行未经授权访问的人）是公司防火墙内部的个人 — 并且大多数（到目前为止）都是公司的正式员工。
不管您选择的安全性类型如何，安装实用工具都将要求您提供 SA 密码。尽管它要求您需要提供“强”密码，这实际上是域密码强度设置的功能。我提倡您使用格式规范的强密码，但是如果使用 Windows 身份验证模式，这一点就并不那么重要了。实用工具不会让您将其保留为空。
 |
安装 SQL Server 计算机管理器扩展
与 SQL Server Express 安装的一个也是唯一一个工具就是 SQL Server 计算机管理器 MMC 管理单元。该工具可用于管理 SQL Server 服务并且使得可以在网络上查看 SQL Server。要安装该组件，请在安装 SQL Server Express 实例过程中使用 Features Selection 对话框（如图 3 所示）选择它即可。
 |
在安装 SQL Server Express 实例后，通过导航到“Protocols for SQLEXPRESS”节点，右键单击然后选择 Enable（如图 4 所示），SQL Server 计算机管理器可以启用 TCP 端口或适当的网络协议。在此例中，我启用了 Named Pipes (Np) 协议。您还必须启动 SQL Brower 服务来提供服务器名称解析。
注 请注意，“Slammer”蠕虫利用这样一个事实，大多数 SQL 服务器在 UDP 端口 1434 公开。这意味着 SQL Server Express 不会受到这种类型的攻击，除非您启用 SQL Browser 服务。
 |
在安装完成后，安装文件（可以包含纯文本或弱加密凭据以及其他敏感配置信息 — 基本上是指服务器的密钥）应该被删除或进行保护。
连接到 SQL Server Express（获得对 SQL Server Express 的访问）
Microsoft 和我希望您使用托管代码来打破对 COM 和 OLE DB 提供程序的依赖性 — 即，SQL Server 提供程序。SqlClient .NET 数据提供程序仍然是最好的选择。如果必须使用 MDAC 和 OLE DB 从基于 COM 的应用程序连接到 SQL Server Express，您可以这么做，但是您无法通过共享的内存提供程序进行连接，并且您将需要确保启动了 SQL Browser 服务。
由于默认安全性设置是集成安全性，您将需要在连接字符串中使用 Integrated Security=SSPI，除非更改为混合模式安全性。您仍然需要在连接字符串中指定初始目录或 Database，以指向 SQL 所针对的特定数据库。当使用 SQL 分析器来监视代码所执行的操作时，我还建议您使用 Application Name 连接字符串参数来唯一地标识您的操作。
使用 AttachDBFilename 进行连接
SQL Server 团队所推荐的新方法是将关键字 AttachDBFilename 添加到连接字符串。如果一直用于 Web 应用程序，对于典型 SQL Server 客户端/服务器前端应用程序而言，这是不常用而且是极少使用的方法。对于说明 SQL Sever 实例的任意连接字符串，您必须按名称（或 IP 地址）指向服务器并提供一个实例名。此外，当使用 AttachDBFilename 关键字指向连接字符串中的文件名时，ADO.NET（或 ADO）会通知目标 SQL Server 实例，您希望将引用的文件“附加”到服务器 — 这样，在打开连接的过程中会将该数据库注册在 SQL Server Master 数据库中。
在附加数据库后，当您引用数据库时，从此时起，该服务器访问引用的文件 (.MDF) 及其附带日志文件 (.LDF)。因为此处有一个 catch 语句，请务必小心。您必须 在连接字符串中指定 Database 关键字。如果不指定，该服务器则无法确定这个新附加的数据库。代码列表 1 显示了被配置为附加并打开一个 .MDF 文件的 ADO.NET Sqlclient.SqlConnection 对象的示例。
代码列表 1. 使用 AttachDBFilename 关键字连接到 SQL Server .MDF 文件。
Try
cn = New SqlConnection("Data Source=.\SQLExpress;" _
& "Integrated Security=True;Database=Biblio;" _
& "Timeout=60;" _
& "Application Name=SQLExpress Test;" _
& "AttachDBFilename=" & strFn)
da = New SqlDataAdapter("SELECT AU_ID, Author, Year_Born from authors", cn)
ds = New DataSet
da.Fill(ds)
DataGridView1.DataSource = ds.Tables(0)
Catch ex As Exception
MsgBox(ex.ToString)
End Try
提示 将新数据库附加到 Master 的过程比简单地打开它要花费更多的时间。确保设置连接字符串 Timeout 关键字，以考虑该增加的时间。
管理附加的 .MDF 数据库文件
尽管打开连接的过程会附加一个数据库，但是当应用程序关闭该连接时，数据库并没有分离。一旦附加，它会永久性地安装在 SQL Server 实例中。这意味着在应用程序结束后，数据库本身对任何应用程序都是可视的，且带有足够的权限。它还表示您需要负责在带有其他应用程序文件的相同目录中维护数据库文件。由于在 SQL Server 运行时，文件受到 Windows 的保护，所以在没有首先从数据库分离时，它不应该被“更新的”版本所覆盖。当然，分离并不困难。您可以从 SQLCMD 中使用以下命令，或使用 SQL Server 2005 GUI 管理工具。另一种方法是使用当使用该数据库的所有应用程序结束时自动关闭数据库文件的 AutoClose 选项。
EXEC sp_detach_db ''MyDb''
GO
请记住要将数据库文件保存在本地硬盘上，而不是保存在共享的网络服务器上。强制 SQL Server 执行通过线缆的物理 I/O（即使它支持该操作）是非常危险的，并且它确实会降低您的性能。
与 JET 数据库不同，备份 SQL Server 数据库文件（可能有若干个文件）非常简单，但是备份过程还涉及了通过 OSQL（其中一个工具）或 SMO 向 SQL Server 发送 T-SQL 命令。数据库可以在任何时间进行备份，可以带有任何数量的登录（和活动）用户。
直接连接到名为 SQL Server Express 的数据库
连接到名为 SQL Server Express 实例（或任意 SQL Server 实例）上的命名数据库的更典型方法是，简单地在实例名后写出计算机名，如代码列表 2 所示。这种方法假设作为目标的 Database 已经注册了 SQL Server Master 数据库。
代码列表 2. 使用对已注册的 SQL Server 数据库的“直接”访问。
cn = New SqlConnection("Data Source=.\SQLExpress;" _
& "Integrated Security=True;Database=Biblio;" _
& "Timeout=60;" _
& "Application Name=SQLExpress Test;" _
& "AttachDBFilename=" & strFn)
注 SQL Server Express 仍然支持连接字符串的“(local)”或“.”表示法来指代 SQL Server 的“默认”实例，但前提是只有您按照我前面所述安装了“默认”实例。我并不建议使用这种方法，因为 SQL Server Express 服务器可能不是服务器上的原始“默认”实例。
使用备用的实例名
您不必使用默认的“SQLEXPRESS”实例名来安装 SQL Server Express。我可以想象出几种情况来说明使用默认实例名并不是很好的解决方案。在这种情况下，您需要使用安装过程中的“高级配置”选项，以选择另一个实例名并在连接字符串中使用这个实例名。这种方法的问题在于，如果应用程序安装实用工具不知道安装在目标服务器上的数据库名称，您的名称可能会与现有名称发生冲突 — 正像在用户系统上安装 SQL Server 的某个其他应用程序可能会与您选择的名称发生冲突一样。这就解释了为什么 SQLEXPRESS 的公用实例名是如此重要的一项创新。
使用别名
从应用程序连接到“公用”服务器名的另一种方法是使用别名。也就是说，您可以使用 SQL 计算机管理器来为 SQL Server 实例指定一个别名（如图 5 所示）。在此例中，我创建了别名“George”，我可以将其用于我的连接字符串中。如果基本服务器发生变化（例如，当我从测试服务器更改为生产服务器时），我只要更改别名，该应用程序就会重定向到正确的服务器。
 |
利用 Windows 身份验证模式管理集成安全性
当您的连接字符串包含关键字 Integrated Security=SSPI 时，ADO.NET（或您所使用的数据访问接口）则使用 Windows 身份验证模式。在幕后，这种模式使用 NTLM (NT LAN Man) Windows NT 质询/响应身份验证协议来验证使用加密的帐户凭据，以便保护传输过程中的密码以防止“刺探者”以离线状态攫取您的凭据。每次打开（或重新打开）连接时，用户凭据会根据域控制器 (Active Directory) 数据库重新进行验证。Microsoft 建议对大多数应用程序使用 Windows 身份验证模式。
注有关安全性支持提供程序 (SSP) 软件包（如 NTLM 和 Kerberos）的详细信息，请参阅 Platform SDK 中的 SSP Packages Provided by Microsoft。
当然，我所编写的用于验证这段代码的测试应用程序可以正常工作（该代码显示在代码列表 1 中）。因为我是以管理员身份登录的，所以我的 Windows 帐户被授予了 SQL Server 上的系统管理员权限。这就是当使用 SQL Server Express 时，为什么不需要使用 SA 帐户或者不需要知道 SA 密码的原因所在。然而，我的确希望最终用户不被授予管理员帐户。当任何人登录到 Windows 域时，域管理员会确定授予他们的权限。该信息存储在 Active Directory 中。这些权限不会传递到 SQL Server，除非您特别地授予这些权限。这意味着（默认情况下）不会 为非管理员授予到服务器或其内容的权限，并且您将需要设置用户、组和角色以管理数据库及其内容。执行该操作的机制在一段时间以来都没有改变，在 SQL Server Books Online 中有对它们的详细说明。有关 SQL Server 安全性非常好的操作的详细信息，请访问 TechNet。
从基本上讲，您需要建立并配置四层安全性。
1.Windows 域帐户：系统管理员需要建立域帐户，包括登录名和（强）密码 — 用户“凭据”。该帐户（默认情况下）是“Domain Users”组的成员。管理员可以建立其他组并根据需要将用户分配到这些组。我通常建立用户的“类”，它按照用户在办公室中被分配的工作角色的类型对其进行分类。例如，我将建立“Accounting Admin1”和“Accounting Admin Lead”组，并将特定的 Windows 域帐户添加到这些组。可以分配给单个 Windows 用户多个角色。
2.工作站和用户的物理安全性。如果在用户离开时，工作站保留为登录状态，或者用户允许其他人使用他们的 Windows 帐户凭据，那么您的安全性已经被洞穿。这一层通常被忽略。这就解释了为什么当用户没有实际出现时 Microsoft 使用密钥访问系统来防止对系统的访问。
3.SQL Server 登录：这是在 SQL Server 上建立的帐户，用于屏蔽连接到 SQL Server 的尝试。您向该列表中添加的每个帐户，都会减弱保护数据的服务器能力，因为它允许额外的 Windows 用户获得对该服务器的访问。当使用集成安全性（我们建议这么做）时，您仍然需要在 SQL Server 上建立一个登录帐户，以允许特定用户或 Windows 域组（例如 Domain Users）对目标数据库进行访问。授予每个登录帐户对一个或多个数据库的访问权限，并且如果初始目录 (Database) 关键字没有在连接字符串中使用，则分配一个所引用的默认数据库。
4.数据库用户：保护的最后一层是在数据库本身中进行管理的。在这种情况下，您需要建立一个或多个数据库用户，为这些用户授予对特定表格、视图、函数和存储过程的访问权限。如果需要，您甚至可以授予对特定列的访问权限。
在任何 SQL Server 数据库上管理安全性帐户的一个方法就是使用 SQLCMD。但是，除非您是数据库管理员 (DBA) 并且具有 T-SQL 的丰富经验，否则这可能有一点令人畏缩。幸运的是，您可以使用 SQL Server 2005 Management Studio（与 SQL 企业管理器等价）来创建数据库用户、组或角色。该工具没有包括在 SQL Server Express 中，因此您需要使用 Microsoft 提供的标准版或开发人员版的工具或使用第三方的一个工具。在创建这些角色后，您可以使用 SQL 工具将这些 T-SQL 命令导出到一个脚本文件。
使用混合模式的安全性
混合模式身份验证是使用 Windows 集成安全性的一个备选方法。在这种情况下，连接字符串 UID 和 PWD 关键字会根据 SQL Server 登录名和密码进行验证。由于这种技术绕过了 Windows 身份验证，它被认为是不太安全的。要使用这种安全性模式（并忽略我们的建议），您需要在安装过程中启用这种混合模式安全性。为此，当使用安装批处理文件时，您可以将 SECURITYMODE 命令参数设置为“SQL”。该选项还可用于 SQL Server Express 交互式安装程序和 SQL Server Express Manager (XM)，其预览版本应该很快就可用了。
SQL Server 安全性常规指南
无论它是每小时百万次点击量的企业服务器还是每千年百万次点击量的小型办公系统，在任意系统上违反安全，都可能意味着公司的崩溃 — 或者丢掉您的工作。由于 SQL Server Express 系统假设应用程序扮演很多安全性角色，需要对其进行准备才能管理 SQL Server 登录、执行周期性维护（例如数据和日志备份）、将备份存储移动到系统外（最好是现场外）以及适于数据库使用的其他维护任务。应用程序还需要采取措施来监视服务器日志的运行状况，并且在遇到问题时对其进报告。
不熟悉 SQL Server 的开发人员通常会忽略一个维护安全性的更基本的方法，例如 SQL Server 具有将对象保护到列的能力。在大多数关键的办公系统中，DBA（如果有）会直接将访问权限限制到基表。此后，DBA 为重点访问数据库的人建立特定的用户和角色帐户，根据专用视图、存储过程和函数启用适当的权限。这样，如果用户凭据被盗，可以访问数据的唯一方法就是通过这些非常简单地限制的机制。
小结
本文介绍了 SQL Server 2005 的新改进的版本，也称为 Express Edition。我讨论了使 SQL Server Express 易于使用并易于保护的差异，并讨论了几个安全性问题，涉及了保护数据、保护服务器以及保护物理系统。我希望这篇概述能够促使您将现有的 JET 应用程序迁移到更安全稳定的 SQL Server 2005 Express Edition 中。
