关于数据库模式在复制过程中持续开发的建议

Question

我目前正在处理一个使用EntityFramework的遗留项目附带的数据库(使用数据模型设计器更新基于现有数据库的代码)。

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

这里的问题是，我们最近开始做一些修改数据库模式的更改工作，所以当我们使用模式比较(visual studio SQL比较功能)时，会有大量的复制sp &模式更改，如果我更新它，基本上会破坏实时数据库。因此，我当前的解决方案是删除开发服务器复制(以便架构在没有复制更改的情况下恢复到应有的样子)，然后执行架构比较和更新，然后再次创建新的合并复制，以便我们的开发人员可以继续处理开发数据库。

我认为这只是一次性的数据库模式更改，但我只是意识到至少在接下来的3-6个月内，这将是持续的更改，因此基本上使每个版本都令人头疼(如果它可以被称为“发布”准备……)

我的SQL和EntityFramework知识有限，有人能为我解释一下吗？

提前感谢！

Answer 1

在开发环境中观察到的合并复制背后的需求是什么？我理解开发人员需要有一个本地副本，他们可以弄乱，运行测试等，但我不知道为什么需要一个完整的发布者-订阅者模型来同步开发/测试环境中的数据库状态，它似乎会给你带来更多的问题，而不是它可能解决的问题，因为模式将在几个月内可伸缩。

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

这是一个稍微更手动的过程，也是一种使用数据库的旧方法，但对我来说，它似乎比定期中断和重新建立复制要容易得多。这将需要一些协作，以确保开发人员不会同时尝试创建备份或对本地副本进行冲突更改，这会破坏主副本；理想情况下，开发人员应该与其他开发人员讨论这类事情，并且您可以使脚本足够智能，以便在生成新的备份之前查找最近的备份。

还有一个想法，不知道根据您目前的进展，它有多可行；从DB-First切换到Code-First并不是不可能的。转换基本上是Database First和Code First的混合过程；DB作为一次性操作进行逆向工程，以生成类似于DB First的模型，但不是EDMX文件，而是将模型写出到源代码文件，然后可以聚合对这些模型文件或上下文映射约定的更改，并将其作为典型代码优先样式的迁移应用于模式。假设您也为迁移准备了实时数据库(并且在模型生成之前使实时数据库处于与主开发数据库相同的状态)，这甚至消除了SQL比较和更新的要求；您只需将迁移应用于实时数据库，就像应用于任何开发实例一样。唯一可能的问题是，有些迁移可能是破坏性的，所以您必须确保您要应用的内容不会清空重命名列中的所有字段。