数据库交付 – 基于状态与基于迁移

对于数据库的开发和部署，主要有两种交付机制 - 基于状态的方法和基于迁移的方法。 在本文中，我们将详细了解这两种方法，并确定现实世界中的用例以及它们适合和不适合的场景。

基于状态的方法

在基于状态的数据库交付中，需要在源代码管理中存储数据库当前状态的快照。每个表、存储过程、视图、触发器都将保存为单独的 sql 文件，这将是数据库对象状态的真实表示。

当您想要修改数据库架构或引用数据时，只需显式提及预期的数据库状态即可。比较工具可以完成所有魔术并生成差异脚本，然后针对数据库执行该脚本。

需要注意的最重要的一点是，在基于状态的方法中，真理系统是源代码本身。应用程序开发人员会喜欢这个，因为它与对类文件进行更改、编译和构建非常相似。另一个好处是，您不必使用基于状态的方法处理 ALTER 脚本 – 架构/数据比较工具负责生成 ALTER 脚本并针对目标数据库运行它，而无需任何手动干预。

基于迁移的方法

在基于迁移的数据库交付中，当您开始处理项目时，您将在存储在源代码管理中的单个迁移脚本中捕获数据库的当前状态，该脚本将成为基本/初始状态。

随着项目随着时间的推移而发展，您将需要对数据库架构和引用数据进行更改。在每个实例上，都需要创建具有增量版本号的迁移脚本。如果要确定数据库的当前状态或在另一个环境中重新创建数据库，则需要按正确的顺序运行所有迁移脚本。

基于迁移的方法中的真实系统是数据库本身。如果必须处理数据密集型操作和 TSQL 查询，此方法可对脚本进行更精细的控制。您有权查看针对目标数据库执行的脚本，并根据需要进行修改。

基于状态与基于迁移及其用例

方案 1
您正在处理一个绿地项目，开发工作大约需要 6 个月才能部署到生产环境。在此期间，您将需要对数据库架构进行多次更改。

在这种情况下，使用基于迁移的方法可能不是一个好的选择，因为您最终会得到一长串迁移脚本，这些脚本可能不利于跟踪。基于状态的方法为开发人员在修改架构方面提供了很大的灵活性，而不必担心在源代码管理中维护许多脚本。

方案 2
使用基于状态的方法，可以将架构置于源代码管理中，这使开发人员能够更好地了解数据库的当前状态，并更方便地查看数据库的当前状态。如果您的 SQL 文件中存在编译时错误，您就会知道。它增强了 Visual Studio IDE 内部开发人员的整体开发体验。

方案 3
：您所在的团队在 SQL 方面的专业知识较少。让他们编写 ALTER 脚本或一些自定义的重构脚本可能会容易出错。在这种情况下，基于州的移民是首选。

方案 4
随着项目的发展，源代码管理中的迁移脚本数量会增加。在基于迁移的方法中，脚本需要运行的脚本的顺序非常关键。
使用基于状态的方法，您不需要处理这些额外的迁移脚本或执行顺序。

方案 5
如果有一个大型团队处理数据密集型项目，其中多个开发人员可能会对同一文件进行更改，则基于迁移的方法可能会产生其他问题。
它可能会导致覆盖其他开发人员所做的更改，或者还可能导致合并冲突，并且必须手动处理它会增加复杂性和容易出错。

方案 6
在一段时间内，基于迁移的方法的部署将花费较长的时间，因为可能会逐个应用对象上的许多更改。在基于状态的方法中，源代码管理存储对象的最终版本，因此可以立即直接应用于数据库 - 因此它速度很快。

方案 7
如果需要对迁移脚本进行更精细的控制，那么基于迁移的方法就是您的不二之选。在基于状态的方法中，不能在对数据库执行之前修改 SSDT 生成的差异脚本。

场景 8
如果您必须处理数据密集型的重构和脚本编写，基于迁移的方法可以像冠军一样处理它 - 因为您可以在对数据库执行迁移脚本之前对其进行审查和编辑。你可以利用你的 T-SQL 专业知识来编写比你认为内部比较团队会生成的更好的脚本。使用基于状态的方法，复杂的重构可能需要多个步骤才能完成。

在结束本文时，您了解到基于状态和基于迁移的方法都有助于进行无缝数据库部署。关于哪种方法更好是一个常见的问题。我想说的是，这取决于你的项目和团队的要求。每种方法都有其优点，因此请选择这种方法，这种方法将使您更有效率并协助进行可靠的数据库部署。