14

我已经建立了一个系统，我采用了模型优先的方法，因为它对我来说更符合逻辑。现在，即使我对模型进行了一些更改，目前我所做的是-

  1. 使用实体框架的从模型生成数据库功能。我创建了一个虚拟数据库并应用这些脚本。它首先删除我所有的数据和表，然后使用实体框架生成的最新 sql 文件更新数据库。
  2. 现在，我使用Visual Studio 的架构比较功能，并为我的本地数据库和生产中的数据库生成迁移脚本。
  3. 我手动浏览脚本并验证它们。完成后，我在生产实例上运行迁移脚本。

问题：主要问题是这真的很乏味，因为我是从我的本地系统做的，连接到我的产品数据库非常慢，有时我的视觉工作室也会崩溃。有没有更清洁的方法来做到这一点？哪个更自动化，以至于我的笔记本电脑并不真正负责生产实例上的数据库迁移？

4

2 回答 2

5

您可以尝试Database Migration Power Pack - 它允许创建更改脚本而不是完整的数据库脚本，但在它后面执行与您手动执行相同的过程。问题是提到的工具不适用于 EF5。

不幸的是， EF 迁移目前不支持通过 EDMX 创建的模型。迁移目前仅支持代码优先方法。

于 2012-08-12T08:08:48.443 回答
3

在 Schema First 设计中，我使用 ApexSQL Diff（很可能与 RedGate 的产品非常相似，可能更便宜一些） -一个好的 3rd 方工具比 VS 数据库项目更容易使用，并且易于使用脚本应用程序工具应用像圆屋。

在 Model First 方法中使用它可以遵循 Schema First 方法，使用模型-Schema-Diff-Schema-Model 的循环，如帖子中所述；考虑以下这些指南/说明，以简化流程。模式差异方法不需要繁琐、缓慢或过度手动。

  1. 当前版本的数据库模式是通过应用一系列数据库补丁（或 DDL/DML 脚本）获得的。

    一个工具（我们使用 RoundHouse）会根据需要自动应用脚本。它记录信息以了解已应用了哪些脚本。应用相同的脚本是幂等的。

  2. 对本地数据库进行差异化；这个本地数据库可以通过所有以前的更改脚本以自动方式建立起来。这个 latest-local 始终是最新模型更改的差异目标。

    远程/实时数据库从不用作差异目标。稍后可以将相同的脚本应用于测试（然后是实时）数据库。由于一切都以相同的方式完成，因此该过程在所有数据库上都是可重复的。

    唯一的“问题”是未经深思熟虑的更新可能会导致数据在新的限制/约束下无效。当然，在推送到实时数据库之前，这很容易识别、修复和重新比较。

  3. 一旦 diff 被提交到源代码控制，它就必须应用于分支。要“撤消”先前提交的更改脚本，需要创建一个应用反向操作的新差异。没有隐式的向下版本。

    我们有一个 [Hg] 模型分支，它有效地充当必须统一针对的模式锁；这可以被视为一个弱点，但它在小团队开发中运作良好。

  4. 像 Huagati DBML/EDMX 这样的工具用于将 Schema 同步回 Model，这在开发时非常有用。这个小宝石确实为自己付出了代价，并且是周期的一部分。当使用它时，也很容易“更新到模型”或在 SSMS（或其他任何东西）中进行 Schema 更改，然后将它们带回来。

Code First 迁移是“好的”（绝对比没有好！），但我只使用它们是因为高级差异工具不支持 Azure SQL（又名 SQL 数据库），因为没有公开各种 sys 信息。（差异可以照常在本地完成，但 ApexSQL Diff 生成的 DDL/DML 并不总是与 Azure SQL 友好 - 另外，我有机会学习一种稍微不同的方法 :-)

通过 Power Pack 进行 Code First 迁移的一些优点：可以在 C# 中执行更新任务，而不是局限于 DDL/DML（可能很方便）、自动降级（虽然我质疑它们的使用）、不需要购买第 3 方工具（可能很昂贵），更容易集成/部署到 Azure SQL，与特定数据库供应商的联系更少（理论上）等。

虽然 Code First 迁移（以及此类迁移的自动化）与绝对可怕的 Drop-and-Recreate 方法相比是一个很好的进步，但我更喜欢在开发时使用专用的 SQL 工具。

于 2013-07-14T01:05:22.393 回答