管理数据库迁移：脚本vs工具

Question

我们的项目有大约20位开发人员，但我们的应用程序使用相对较少的数据库。我们收集了大约5个数据库，每个数据库都非常小，每个数据库少于20个，其中没有数据库有数百万行或任何大的数据库。

我们有表的两个选项如何随时间推移管理数据库的演变：

• 一些一种工具。目前，我们正在使用Visual Studio数据库项目，其中包含模式的当前定义，并查看参考数据库以生成diff脚本。然后，我们使用这个diff脚本使参考数据库保持最新。
• 使用版本脚本从基线构建数据库。脚本被手动放置在源代码控制中。将数据从旧列/表移动到新的任何数据迁移都将成为这些脚本的一部分。 DB中会记录一个版本，升级会在DB版本和当前版本之间运行所有脚本。

第二个选择似乎是广泛使用，我发现了一个深入讨论这里：http://odetocode.com/blogs/scott/archive/2008/01/31/versioning-databases-the-baseline.aspx

我们有什么我们目前得到的问题是，我们没有访问过我们的Production数据库。这意味着要创建一个发布包，我们必须将生产的备份恢复到另一个位置，根据该参考数据库生成差异并将脚本提供给生产数据库团队。所以我们的产品发布与其他环境不同。

这使得运行版本脚本吸引力，因为我们在各种环境中使用相同的脚本的想法，有部署无特设工作（如手工刺的恢复参考DB）。但考虑到我们的数据库规模这么小，我觉得我们很难成为DB工具的难题。我们想要的是尽可能简单的东西，这很容易理解。

执行工具，如为这种情况的展鹏的套件意义，还是应该去版本的脚本？成本并不是一个问题，更重要的是创建一个成功之谷，其中维护和部署数据库尽可能基本和自动化。

Answer 1

根据我的经验，总是有比它更多的是模式更改。如果将列分成两列，或者将列转移到单独的表或其他类似的东西，则需要迁移模式和数据。

任何工具或脚本可以让你自动迁移的实际数据。在最多的时候，你会得到一个模式的差异，你的开发人员可能会发现这个模式可以作为数据库版本迁移脚本的提醒/检查列表（在单个事务中完成创建/修改/删除和插入/更新/删除的序列） 。

Answer 2

我在红门产品经理SQL比较，这两个数据库之间产生差异的脚本。我希望你看看我们的SQL源代码控制工具，它可以让你在开发时跟踪模式变化。当涉及到部署时，如果您知道哪个模式版本正在生产中，您可以从源代码控制版本生成部署脚本。当然，在生产运行之前，您应该始终在分段环境中进行测试。

Scott的文章在迁移脚本方面非常出色，Denis提到了更复杂的更改，这些更改实际上不会被比较工具猜中，因此需要自定义迁移脚本进行适当的管理和使用。SQL Compare的下一个版本将与SQL Source Control一起管理您的模式版本和您的迁移脚本，使您能够获得两全其美的优势。如果你想看到这个早期的截图，请给我发电子邮件在大卫点阿特金森在red-gate dot com。我真的很喜欢讨论你的要求，所以我们可以更好地设计这个工具。

Answer 3

迁移时，需要脚本化数据库，数据库对象，数据库权限，服务器登录名，服务器权限，sql作业，sql邮件配置文件， 链接的服务器。 下面的power shell脚本将帮助你获得它。请在运行Power Shell脚本之前仔细阅读说明。

https://gallery.technet.microsoft.com/SCRIPTING-DB-DB-OBJECTS-DB-81bba072