我有一个想法可以供我的开发人员使用，并且基本上需要反馈。
这个想法是拥有一个集中的 SQL Server 数据库服务器供所有开发人员使用。
每个开发人员都可以在特定项目的服务器上拥有自己的数据库（例如，SW_ProjectName）。
因此，如果开发人员休假一周，而我们需要在截止日期前完成，我们可以通过更改本地配置连接字符串轻松连接到他们的数据库。
除此之外，它们将是一个测试数据库（例如ProjectName_Testing），开发人员将使用它在部署到 Staging 之前运行测试他们的 sprint。
任何人都可以想到这种方法的优点和缺点，而不是让每个人都拥有自己的本地数据库进行开发。
我不知道对此有一个好的综合解决方案。
本地开发意味着开发人员不会破坏其他人针对共享数据库编写自己的代码。但是，当您获得最新的代码时，您还需要使数据库进入正确的状态以匹配您合并的代码更改。如果两个人同时进行更改，合并可能会很困难，因为数据库升级脚本可以不相容。列顺序在数据库中通常无关紧要，但数据库不同可能有点烦人。
有很好的工具可以比较模式和数据并应用更改。我会说模式的目标应该是相同的。但是，通常您希望在开发人员之间更新查找类型数据而不是常规应用程序数据（新客户类型，但不是新客户）。您可能想要更新的配置数据，但有时只是一个子集（新打印机选项，但不是文件路径设置）。
您可能会认为，理想情况下，您可以在每次合并更改后完全重建本地数据库。如果您已经通过应用程序设置了一堆测试场景以进行测试（而不是在构建脚本中），那么您现在没有将这些更改返回到数据库中的脚本。随着数据库模式范围的增加，这变得更加困难——代理键和父子关系都可能具有复杂的依赖关系。
在中央数据库的理想场景中，您应该让开发人员 DBA 管理应用程序的数据库接口并进行控制，以便公开的接口随着时间的推移不断发展，并且该级别的所有开发人员将同时看到相同的接口. 但是你有两个独立的小组来协调他们不同的功能时间线。
我认为这在很大程度上说明了为什么人们仍然被各种其他方法所吸引，这些方法更多地强调代码而不是数据库。最终，我认为这只是改变了问题。