我目前正在处理一个使用EntityFramework的旧项目附带的数据库（使用数据模型设计器基于现有数据库更新代码）
目前，我正在处理主副本，而我们的开发人员则在其本地PC上使用SQL Server合并复制在本地工作。
这里的问题是，我们最近开始进行一些修改数据库架构的更改工作，因此，当我们使用架构比较（Visual Studio SQL比较功能）时，会有大量的复制sp和架构更改，如果我确实进行了更新，它们基本上会损坏实时数据库。因此，我当前的解决方案是删除开发服务器复制（以便使架构返回到应具有的外观而无需更改复制），然后进行架构比较和更新，然后再次创建新的合并复制，以便我们的开发人员可以继续工作在开发数据库上。
我以为这是一次性的数据库模式更改，但我意识到至少在接下来的3-6个月内它将是连续更改，因此基本上使每个版本都感到头疼（如果可以将其称为“发布”）准备...）
我的SQL和EntityFramework知识有限，请问有人可以帮我一下吗？
提前致谢！
最佳答案
在开发环境中，合并复制背后观察到的需求是什么？我了解开发人员需要拥有一个可能会引起混乱的本地副本，并对它们进行测试等，但是我却迷失了为什么需要一个完整的Publisher-Subscriber模型来同步开发人员/测试环境中的数据库状态，而且似乎考虑到该架构将在几个月内具有延展性，将给您带来的问题超出了可能解决的问题。
如果合并复制不是对开发环境的硬性要求，我建议您将其替换为将更改分发到本地副本的替代方法。如果开发人员无论如何都在使用数据库的完整副本，我认为没有理由不编写脚本来备份开发服务器上的主副本，然后将其拉下并在本地还原。然后，将使用更改脚本来完成对该模式的更改，这些更改脚本可以在应用到主数据库之前在本地运行和测试，然后随备份/还原脚本的另一次运行按需分发。
这是一个稍为手动的过程，并且是使用DB的较旧的方法，但是对我来说，这比定期中断并重新建立复制要好得多。需要进行一些协作，以确保开发人员不会尝试同时进行备份或对本地副本进行冲突的更改，而这些更改会分散在主副本上。理想情况下，您的开发人员应该就此类问题进行相互讨论，并且您可以使脚本足够聪明，以便在生成另一个备份之前先查找最近的备份。
再想一想，根据您的最新进展，不知道它有多可行；从DB-First切换到Code-First并非不可能。转换基本上是数据库优先和代码优先的混合过程。 DB被一次性工程化以生成类似于DB First的模型，但是代替EDMX文件，该模型被写到源代码文件中，并更改为这些模型文件或上下文上的映射约定然后可以将其聚合，并以典型的“代码优先”样式将其应用于迁移。假设您还为迁移准备了实时数据库（并且在模型生成之前，实时数据库处于与主Dev数据库相同的状态），这甚至消除了SQL比较和更新的需求；您只需将迁移应用于实时数据库，就如同将其应用于任何Dev实例一样。唯一的难题是，某些迁移可以以破坏性方式编写，因此您必须确保要应用的内容不会清除重命名列中的所有字段。