【IT168 服务器学院】什么是 SQL Server Express？
　　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 应用程序和数据库的自定义安装脚本一起使用的。