在复制时对数据库模式进行持续开发的建议

Question

我目前正在开发一个使用 EntityFramework 的遗留项目附带的数据库（使用数据模型设计器根据现有数据库更新代码）

目前我在主副本上工作，我们的开发人员在本地 PC 上使用 SQL Server 合并复制在本地工作。

这里的问题是我们最近开始做一些修改数据库架构的更改工作，所以当我们使用架构比较（Visual Studio SQL 比较功能）时，基本上如果我更新的话，会有大量的复制 sp & 架构更改它会破坏实时数据库。所以我当前的解决方案是删除开发服务器复制（以便架构回到它应该看起来像没有复制更改），然后进行架构比较和更新，然后再次创建一个新的合并复制，这样我们的开发人员就可以继续工作在开发数据库上。

我以为这只是一次性的 db 架构更改，但刚刚意识到至少在接下来的 3-6 个月内会持续更改，所以基本上每个版本都会让人头疼（如果它可以称为“发布”准备...）

我的 SQL 和 EntityFramework 知识有限，谁能帮我解释一下？

提前致谢！

Answer 1

在开发环境中观察到合并复制背后的需求是什么？我理解开发人员需要有一个他们可以处理的本地副本、运行测试等，但我不明白为什么需要一个完整的发布者-订阅者模型来同步开发/测试环境中的数据库状态，而且似乎考虑到架构将在几个月内具有延展性，给您带来的问题多于它可能解决的问题。

如果合并复制不是开发环境的硬性要求，我建议您将其替换为将更改分发到本地副本的替代方法。如果开发人员无论如何都在使用数据库的完整副本，我认为没有理由不编写一个脚本来备份开发服务器上的主副本，然后将该文件拉下来并在本地恢复它。然后，对该模式的更改将通过更改脚本完成，该脚本可以在应用到主数据库之前在本地运行和测试，然后随备份/恢复脚本的另一次运行按需分发。

这是一个稍微手动的过程，也是一种使用数据库的旧方式，但对我来说，它似乎比定期中断和重新建立复制更容易接受。这需要一些协作，以确保开发人员不会同时尝试进行备份或对本地副本进行冲突更改，从而导致主副本崩溃；理想情况下，您的开发人员应该就这类事情相互交谈，并且您可以使脚本足够聪明，以便在生成另一个备份之前查找最近的备份。

再想一想，考虑到你迄今为止的进展，不知道它是否可行；从 DB-First 切换到 Code-First 并非不可能。转换基本上是 Database First 和 Code First 的混合过程； DB 被逆向工程为一次性操作以生成类似于 DB First 的模型，但不是 EDMX 文件，而是将模型写入源代码文件，并对这些模型文件或上下文中的映射约定进行更改然后可以聚合并以典型的 Code First 风格作为迁移应用到架构中。假设您也为迁移准备了活动数据库（并且在模型生成之前使活动数据库与主开发数据库处于相同状态），这甚至消除了 SQL 比较和更新的要求；您只需将迁移应用到实时数据库，就像应用到任何 Dev 实例一样。唯一潜在的问题是某些迁移可以破坏性地编写，因此您必须确保您将要应用的内容不会清除重命名列中的所有字段。