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

就像之前在此处围绕“ 开发人员是否能够查询生产数据库？ ” 这一问题的脉络一样，我想让您对另一个特别烦人的话题发表想法！

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

具体而言，这样做是为了确保：

• 开发服务器和生产之间的补丁程序级别一致性
  
• 能够证明和验证上面的任何补丁
  
• 数据安全; 仅开发服务器上的数据用于开发
  
• 可恢复性；数据是可恢复的并且仍在备份
  
• 整理差异可能会在转移到生产中时引​​起问题

在我看来，所有这些论点都是特别无效的，也许是补丁的例外。但是，如果本地计算机上的数据库仅用于开发活动而不是测试，则当应用程序通过Test / UAT等进行生产时，将证明补丁是可行的。

排序规则似乎不是一个正当的理由，好像这是数据库的问题一样，无论如何在创建数据库时都应进行设置。据我所知，只有SharePoint和SCCM对此有问题；）

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

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

谁能看到任何问题吗？我想念什么吗？

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

是。所有开发人员都应具有SQL Server的本地实例和共享的SQL Server实例。它们出于不同的目的而存在。两者都是需要的。

也许您当前的环境看起来像这样？

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

1. 无法适当地进行源代码控制。 大！
2. 没有服务器级权限就无法进行性能调整。
3. 无法进行实验而不会影响他人。

这种模式会导致开发人员冲突。冲突的一种症状是数据库蔓延。随着开发人员寻找安全，隔离的空间来开展工作，创建了许多数据库。组织坚持这种模式有几个原因。首先是他们没有投资适当的源头控制系统。另一个是他们只是继承了这种设计模式，而不必费心去更改它。微软一直在稳步向这种模式迈进，并朝着类似的方向发展...

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

上面使用的本地数据库可以是LocalDB，Express或Developer版本。简单对话在这里权衡了每个优点和缺点。微软为本地开发数据库编写了这么多选择是有原因的：LocalDB，Express，Developer ..我们应该使用它们！

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

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

对我来说，所有这些论点都是无效的

好。但是他们对我们其他人而言却不是。为什么？

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

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

修补程序可以解决稳定性和数据损坏问题，否则将困扰开发人员。无论如何，都应该在开发机器上完成。

数据安全; 仅开发服务器上的数据用于开发

将“应该是”与“应该是”分开是很有用的。开发人员最终在其数据库上获得了敏感的数据（不一定是PII，但也没有释放数据）。它发生了。

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

超级重要。

整理差异可能会在转移到生产中时引​​起问题

只有SharePoint和SCCM可以解决此问题

使用临时表的任何内容都会出现此问题。这是非常普遍的。您永远不会注意到它，因为大多数人一开始都希望使用标准排序规则。

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

我们为什么要假设呢？事情通常从开发到生产。第一次如何增加生产量？纯脚本？不一定在应用程序已经进行预生产一段时间后。

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

您只需要发布关于您做什么和不支持以及为什么的声明。

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

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

从概念上讲，您处在正确的轨道上。对于拥有成熟开发流程/软件开发生命周期（SDLC）（包括源代码控制，持续集成（CI），自动化测试）和知道如何管理各种环境和工作站以使其保持同步的IT组的组织关于软件和补丁程序级别，以及 训练有素的开发人员，包括a）遵循该过程，b）一起工作以及c）与IT一起工作，那么拥有50个（或很多）开发DB可以工作：

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

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

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

但是，有很多问题要考虑：

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

• 从排序的角度来看，SQL Server Express LocalDB确实有一个特别令人讨厌的细微差别/限制/限制：

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

  实例级别的归类不仅会影响tempdb（即db范围的对象名解析和临时表的默认归类，但不会影响表变量），还会影响局部变量名称，游标名称/参数名称和goto标签名称。因此，如果您的生产服务器的实例级排序规则不是SQL_Latin1_General_CP1_CI_AS，则LocalDB不是一个好的选择。

• 您正在使用企业版功能吗？如果仅是进行在线索引重建而已，那可能就没有关系了。但是，如果您使用的是“表分区”之类的方法，那么LocalDB并不是一个不错的选择。

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

真正的原因是：在团队环境中使用它的诱人原因是什么？在各种工作中，我一直都是由App开发人员和数据库工程师组成的小组工作，尽管App开发人员有时会模拟存储过程只是为了使其更快地完成（我们中的DBE不够多），但DBE却做了大部分工作。数据库编程，包括检查（即修复）App Devs编写的任何代码。使用LocalDB会使小组工作变得更加困难。而且，尽管使用SQL Server Express（甚至是Developer Edition）在每个可远程访问的开发人员工作站上拥有个人实例（使协作更容易），但实际上并不需要这种隔离级别，因为这种隔离很少见。一个项目的数据库更改会对另一个项目产生负面影响。

当然，我们中那些曾经担任过数据库工程师（DBE）的人确实在本地安装了Express Edition和/或Developer Edition。但是，这样做是要进行测试，与共享服务器相比，该测试需要对实例级配置/安全性等进行更多控制。而且我偶尔但不经常使用本地实例。但是对于我的个人项目，我喜欢 LocalDB并经常使用它。