就像之前在此处发布的关于“开发人员应该能够查询生产数据库吗？ ”的问题的脉络，我想了解您对另一个特别烦人的话题的看法！
许多公司阻止开发人员在开发机器上安装 SQL Server Express 等，而是提倡使用集中式开发 SQL Server。
具体而言，这样做是为了确保：
- 开发服务器和生产服务器之间的补丁级别一致性
- 能够证明和验证上述任何补丁
- 数据安全; 只有开发服务器上的数据用于开发
- 可恢复性；数据可恢复且仍在备份
- 移至生产时可能导致问题的排序规则差异
对我来说，所有这些论点都特别无效，也许修补的除外；但是，如果本地计算机上的数据库纯粹用于开发活动，而不是测试，那么当应用程序通过测试/UAT 等进入生产时，补丁将被证明。
排序规则似乎不是一个正当的理由，好像这是数据库的一个问题，无论如何都应该在创建它时设置它。据我所知，只有 SharePoint 和 SCCM 有这方面的问题；）
现在，假设它仅用于开发，并且数据库不会“移动”到生产环境，唯一的移动将是：
- 创建用于部署到生产的数据库的脚本
- 来自“生产”第三方系统的备份在适合验证和开发的情况下被恢复和截断
任何人都可以看到任何问题吗？我错过了什么吗？
我想最大的担忧之一是本地数据库实例过时的能力，但这是一个软件管理问题，而不是一个 IMO 的 DBA。
好的。但他们不是我们其他人。为什么？
补丁可以修复稳定性和数据损坏问题，否则会困扰开发人员。无论如何，它应该在开发机器上完成。
将“应该是什么”与“是什么”分开是很有用的。开发人员最终会在其数据库中获得敏感（不一定是 PII，但也不是免费）数据。它发生了。
超级重要。
任何使用临时表的东西都会有这个问题。这是非常常见的。您永远不会注意到它，因为大多数人首先会选择标准排序规则。
为什么我们会这样假设？事情经常从开发到生产。您还如何第一次获得生产填充？纯脚本？当应用程序已经预生产了一段时间时，不一定。
您只需要发表一份声明，说明您支持和不支持的内容以及原因。
LocalDB 现在是 SSDT 的核心部分，也是不可避免的。但是它不能远程访问，也没有调度组件（Express 也有类似的问题）。因此，在备份、维护和完整性检查方面，DBA 通常不支持它。
但是整合到集中式开发服务器仍然有意义。既然开发者版是免费的，就更容易证明拥有更多它们的合理性。
从概念上讲，您走在正确的轨道上。对于拥有成熟的开发流程/软件开发生命周期 (SDLC) 的组织，包括源代码控制、持续集成 (CI)、自动化测试，以及知道如何管理各种环境和工作站以保持同步的 IT 团队关于软件和补丁级别，以及 a) 遵循流程，b) 一起工作，以及 c) 与 IT 合作的纪律严明的开发人员，那么拥有 50 个（或任意数量的）开发数据库就可以工作：
但是，与大多数其他事情一样，这实际上取决于情况的背景。
拥有单独的开发数据库的一个好处是可以同时处理各种项目而不会相互影响。（当然，这可能是唯一的好处。）
但是，有各种问题需要考虑：
团队的规模有多大，有多少人在从事任何特定项目？你在一个项目上工作的人越多，你就越需要一个共享/集中的开发服务器，以便每个人都能获得所有的变化。
排序方面，SQL Server Express LocalDB确实有一个特别烦人的细微差别/限制/限制：
实例级排序规则不仅影响
tempdb（即 db 范围的对象名称解析，以及临时表的默认排序规则，但不影响表变量），还影响局部变量名称游标名称/参数名称和goto标签名称。因此，如果您的生产服务器的实例级排序规则不是SQL_Latin1_General_CP1_CI_AS，那么 LocalDB 不是一个好的选择。您使用的是企业版功能吗？如果只是进行在线索引重建的问题，那么这可能无关紧要。但是，如果您使用的是 Table Partitioning 之类的东西，那么 LocalDB 就不是一个好的选择。
也许最大的问题是任何可能导致错误的环境差异（操作系统级别、软件补丁级别、实例配置、数据库配置等）引起的潜在问题的总体范围扩大。虽然我们已经接受（在一般意义上）自动化测试/QA/UAT 会发现这些问题，但这并不能保证！鉴于人类会犯错误并且人类需要提出所有可以检查所有代码路径和所有数据变体（类型、大小等）的测试，很可能任何数量的场景都不会进行测试并且错误可以通过并且直到客户在生产中发现它才被注意到。无论如何都会发生这种情况，但是使用 LocalDB 的机会会增加，这样每个开发人员都可以拥有自己的私有数据库。
它真正归结为：在团队环境中使用它的令人信服的理由是什么？在各种工作中，我一直在有应用程序开发人员和数据库工程师的小组中工作，虽然应用程序开发人员有时会模拟存储过程只是为了更快地完成它（我们 DBE 不够多），但 DBE 完成了大部分工作数据库编程，包括检查（即修复）应用程序开发人员编写的任何代码。使用 LocalDB 会使团队工作变得更加困难。在使用 SQL Server Express（甚至开发人员版）在每个开发工作站上拥有可远程访问的个人实例时——使协作更容易——实际上从来不需要那种级别的隔离，因为这种情况很少见。一个项目的数据库更改会对另一个项目产生负面影响。
当然，我们这些数据库工程师 (DBE) 确实在本地安装了 Express Edition 和/或 Developer Edition。但是，这是为了进行测试，需要对实例级配置/安全等进行更多控制，而不是在共享服务器上允许的。我偶尔使用本地实例，但不是很频繁。但是对于我的个人项目，我喜欢LocalDB 并且经常使用它。
是的。所有开发人员都应该有一个本地的 SQL Server 实例和一个共享的 SQL Server 实例。它们存在于不同的目的。两者都是需要的。
也许您当前的环境看起来像这样？
上面，几个开发人员正在编写更改并将它们部署到公共 SQL Developer 数据库中。这是不好的。Microsoft MVP Troy Hunt在此处记录了这种过时方法的一些痛点。主要的是...
这种模式会导致开发人员冲突。冲突的一个症状是数据库蔓延。许多数据库是在开发人员寻找一个安全、隔离的空间来完成他们的工作时创建的。组织坚持这种模式有几个原因。首先是他们没有投资合适的源代码控制系统。另一个是他们只是继承了这种设计模式，懒得去改变它。微软一直在稳步摆脱这种模式，进入更像这样的东西......
在上图中，每个开发人员都使用 Visual Studio 将他的数据库更改写入并保存到 SQL Server 的本地实例中。然后将这些本地更改同步到适当的源代码控制系统中。在这里，每个开发人员都可以在一个他的更改在签入之前不会影响其他任何人的环境中进行设计和试验。到那时，冲突就会得到解决。
上面使用的本地数据库可以是 LocalDB、Express 或 Developer 版本。Simple-Talk 在这里很好地权衡了每种方法的优缺点。Microsoft 为本地开发数据库编写了如此多的选择是有原因的：LocalDB、Express、Developer.. 我们应该使用它们！
如果您需要选择，很难不争辩说每个开发人员都安装了本地版本SQL Server Developer版本。它是完全免费的，并且与企业版具有相同的功能。它将允许您的整个团队以安全的方式在整个 Microsoft BI 堆栈（SQL Server、SSIS、SSRS 和 SSAS）中进行探索和设计。
我们仍然可以保留公共数据库，但它不应该用于开发，应该用于测试。这是一个系统级设置与生产同步的服务器。硬件、操作系统、补丁等。