应该允许开发人员使用 LocalDB 还是“开发”实例？

Question

就像之前在这里发布的关于“开发人员应该能够查询生产数据库吗？ ”的问题的脉络一样，我想了解您对另一个特别烦人的话题的看法！

许多公司阻止开发人员在开发机器上安装 SQL Server Express 等，而是提倡使用集中式开发 SQL Server。

具体来说，这样做是为了确保：

• 开发服务器和生产之间的补丁级别一致性
  
• 能够证明和验证上述任何补丁
  
• 数据安全; 只有开发服务器上的数据才能用于开发
  
• 可恢复性；数据可恢复且仍在备份
  
• 转移到生产时可能导致问题的排序规则差异

对我来说，所有这些论点都特别无效，也许修补程序除外。但是如果本地机器上的数据库纯粹用于开发活动，而不是测试，那么当应用程序通过测试/UAT 等进入生产时，补丁将被证明。

排序规则似乎不是一个有效的理由，好像这是数据库的一个问题，它应该在创建时设置。据我所知，只有 SharePoint 和 SCCM 有这方面的问题；)

现在，假设它仅用于开发，并且数据库不会“移动”到生产中，唯一的移动是：

• 创建用于部署到生产的数据库的脚本
• 来自“生产”第三方系统的备份在适合验证和开发的情况下被恢复和截断

任何人都可以看到任何问题吗？我错过了什么吗？

我想最大的问题之一是本地数据库实例过时的能力，但那是软件管理问题，而不是 DBA 的 IMO。

Answer 1

对我来说，所有这些论点都特别无效

好的。但他们对我们其他人来说不是。为什么？

开发服务器和生产之间的补丁级别一致性

当应用程序通过测试时，补丁将被证明

修补可以修复稳定性和数据损坏问题，否则这些问题会困扰开发人员。无论如何，它应该在开发机器上完成。

数据安全; 只有开发服务器上的数据才能用于开发

将“应该是什么”与“是什么”分开是很有用的。开发人员最终会在他们的数据库中获得敏感（不一定是 PII，但也不是免费的）数据。它发生了。

可恢复性；数据可恢复且仍在备份

超级重要。

转移到生产时可能导致问题的排序规则差异

只有 SharePoint 和 SCCM 有这方面的问题

任何使用临时表的东西都会有这个问题。这是非常常见的。您永远不会注意到它，因为大多数人首先会选择标准的校对规则。

假设它仅用于开发，并且数据库不会“移动”到生产

我们为什么要这样假设？事情往往从开发到生产。第一次生产时，您还怎么做？纯脚本？当应用程序已经预生产一段时间时，不一定。

我想最大的问题之一是本地数据库实例过时的能力，但那是软件管理问题，而不是 DBA 的 IMO。

您只需要发表一份关于您支持和不支持的内容以及原因的声明。

LocalDB 现在是 SSDT 的核心部分，也是不可避免的。但是它不能远程访问并且没有调度组件（Express 有类似的问题）。因此，在备份、维护和完整性检查方面，DBA 通常不支持它。

但是整合到集中式开发服务器仍然有意义。现在开发者版是免费的，更容易证明拥有更多。

Answer 2

是的。所有开发人员都应该拥有一个本地 SQL Server 实例和一个共享 SQL Server 实例。它们的存在有不同的目的。两者都需要。

也许你现在的环境是这样的？

上面，几个开发人员正在编写更改并将其部署到公共 SQL Developer 数据库中。这不好。Microsoft MVP Troy Hunt在此记录了这种过时方法的一些痛点。主要的是...

1. 无法适当地进行源代码控制。 大的！
2. 如果没有服务器级权限，则无法进行性能调整。
3. 无法在不影响他人的情况下进行实验。

这种模式会导致开发人员冲突。冲突的症状之一是数据库蔓延。许多数据库是在开发人员寻找安全、隔离的空间来完成工作时创建的。组织坚持这种模式有几个原因。首先是他们没有投资适当的源代码控制系统。另一个原因是他们只是继承了这种设计模式，懒得去改变它。微软一直在稳步摆脱这种模式，转向类似这样的模式……

在上图中，每个开发人员都使用 Visual Studio 将其数据库更改写入并保存到 SQL Server 的本地实例中。然后，这些本地更改会同步到适当的源代码控制系统中。在这里，每个开发人员都可以在一个环境中进行设计和实验，在签入之前，他的更改不会影响其他任何人。到时候矛盾就会得到解决。

上面使用的本地数据库可以是 LocalDB、Express 或 Developer 版本。Simple-Talk 在权衡每种方案的优缺点方面做得非常出色。Microsoft 为本地开发数据库提供了如此多的选择是有原因的：LocalDB、Express、Developer..我们应该使用它们！

如果您需要选择，很难不争辩说每个开发人员都安装了本地版本的SQL Server Developer版本。它完全免费，并且具有与企业版相同的功能。它将允许您的整个团队以安全的方式在整个 Microsoft BI 堆栈（SQL Server、SSIS、SSRS 和 SSAS）中探索和设计。

我们仍然可以保留公共数据库，但它不应该用于开发，而应该用于测试。它是系统级设置与生产同步的服务器。硬件、操作系统、补丁等。

Answer 3

从概念上讲，您走在正确的轨道上。对于拥有成熟的开发流程/软件开发生命周期 (SDLC) 的组织，其中包括源代码控制、持续集成 (CI)、自动化测试，以及知道如何管理各种环境和工作站以保持同步的 IT 团队关于软件和补丁级别，以及 纪律严明的开发人员，a) 遵循流程，b) 共同工作，c) 与 IT 部门合作，那么拥有 50 个（或任意数量）的开发 DB 就可以发挥作用：

• 是的，可以在任意数量的工作站上维护一致的软件和补丁级别。
• 是的，任何“问题”都可能在自动化测试和/或 QA/UAT 环境中出现。
• 许多开发数据库并不那么容易备份，但也不是不可能。如果使用漫游配置文件，则每个 Windows 用户的“本地设置”文件夹中的数据文件可能更容易备份。或者至少可以由 IT 编写脚本从所有开发工作站获取文件，类似于他们确保所有内容都得到正确修补的方式。

但是，与大多数其他事情一样，这实际上取决于具体情况。

拥有单独的开发数据库的好处之一是可以同时处理多个项目而不互相影响。（当然，这可能是唯一的好处。）

然而，有各种问题需要考虑：

• 团队规模有多大？有多少人正在从事某个特定项目？参与项目的人员越多，您就越需要共享/集中式开发服务器，以便每个人都能获得所有更改。

• 在排序方面，SQL Server Express LocalDB确实有一个特别令人讨厌的细微差别/限制/局限性：

  LocalDB 的实例排序规则设置为 SQL_Latin1_General_CP1_CI_AS 并且无法更改。通常支持数据库级、列级和表达式级排序规则。包含数据库遵循包含数据库排序规则定义的元数据和 tempdb 排序规则。

  实例级排序规则不仅影响tempdb（即数据库范围的对象名称解析和临时表的默认排序规则，但不影响表变量），而且还影响局部变量名称、游标名称/参数名称和goto标签名称。因此，如果您的生产服务器具有除 之外的实例级排序规则SQL_Latin1_General_CP1_CI_AS，那么 LocalDB 不是一个好的选择。

• 您使用的是企业版功能吗？如果这只是进行在线索引重建的问题，那么这可能并不重要。但如果您使用表分区之类的东西，那么 LocalDB 就不是一个好的选择。

• 也许最大的问题是由环境差异（操作系统级别、软件补丁级别、实例配置、数据库配置等）引起的潜在问题的总体范围增加，这些差异可能导致错误。虽然我们（在一般意义上）已经接受自动化测试/QA/UAT 会发现这些问题，但这并不能保证！鉴于人类会犯错误，并且人类需要提出所有测试来检查所有代码路径和所有数据变体（类型、大小等），因此很可能不会测试任何数量的场景并且错误可能会通过并且不会被注意到，直到客户在生产中发现它。这种情况无论如何都会发生，但是当使用 LocalDB 时，这种情况会增加，这样每个开发人员都可以拥有自己的私有数据库。

真正归结为：在团队环境中使用它的令人信服的原因是什么？在各种工作中，我总是在有应用程序开发人员和数据库工程师的小组中工作，虽然应用程序开发人员有时会模拟一个存储过程只是为了更快地完成它（我们 DBE 的数量还不够），但 DBE 完成了大部分工作数据库编程，包括检查（即修复）应用程序开发人员编写的任何代码。使用 LocalDB 会使团队工作变得更加困难。虽然使用 SQL Server Express（甚至 Developer Edition）在每个可远程访问的开发工作站上拥有个人实例（从而使协作更容易），但实际上从来没有必要具有这种级别的隔离，因为很少有一个项目的数据库更改会对另一个项目产生负面影响。

当然，我们这些数据库工程师 (DBE) 确实在本地安装了 Express Edition 和/或 Developer Edition。但是，这是为了进行需要比共享服务器上允许的实例级配置/安全性等更多控制的测试。我偶尔使用本地实例，但不是很频繁。但对于我的个人项目，我喜欢LocalDB 并且经常使用它。