我们的项目有大约20个开发人员，但我们的应用程序对数据库的使用相对较少。我们有大约5个数据库集合，所有这些集合都非常小，每个集合不到20个表，没有任何包含数百万行或任何大型内容的表。
我们有两种选项来管理数据库随时间的演变：
1.某种工具。目前我们正在使用Visual Studio数据库项目，其中包含模式的当前定义，并查看参考数据库以生成差异脚本。然后，我们使用此差异脚本将参考数据库更新到最新版本。
2.使用版本脚本从基线构建数据库。手动将这些脚本放置在源代码控制中。任何数据迁移以将数据从旧列/表移动到新列/表都将成为这些脚本的一部分。在DB中记录一个版本，并升级将运行DB版本和当前版本之间的所有脚本。
第二个选项似乎被广泛使用，我在这里找到了一个深入的讨论：http://odetocode.com/blogs/scott/archive/2008/01/31/versioning-databases-the-baseline.aspx 我们现在所拥有的问题是我们无法访问我们的生产数据库。这意味着要创建发布包，我们必须将生产环境的备份还原到另一个位置，针对该参考数据库生成差异，并将脚本提供给生产数据库团队。因此，我们发布到生产环境与我们的其他环境不同。
这使得运行版本化脚本的想法很有吸引力，因为我们在所有环境中使用相同的脚本，而且在部署过程中没有临时工作（例如手动恢复prod到参考DB）。但是，考虑到我们具有如此小规模的数据库情况，我觉得我们几乎不可能成为存在的DB工具的困难案例。我们想要的是尽可能简单易懂的东西。
像RedGate套件这样的工具是否适用于这种情况，或者我们应该使用版本脚本？成本并不是太大的问题，更多的是创建一个成功之坑，使维护和部署DB尽可能基本和自动化。
我们有两种选项来管理数据库随时间的演变：
1.某种工具。目前我们正在使用Visual Studio数据库项目，其中包含模式的当前定义，并查看参考数据库以生成差异脚本。然后，我们使用此差异脚本将参考数据库更新到最新版本。
2.使用版本脚本从基线构建数据库。手动将这些脚本放置在源代码控制中。任何数据迁移以将数据从旧列/表移动到新列/表都将成为这些脚本的一部分。在DB中记录一个版本，并升级将运行DB版本和当前版本之间的所有脚本。
第二个选项似乎被广泛使用，我在这里找到了一个深入的讨论：http://odetocode.com/blogs/scott/archive/2008/01/31/versioning-databases-the-baseline.aspx 我们现在所拥有的问题是我们无法访问我们的生产数据库。这意味着要创建发布包，我们必须将生产环境的备份还原到另一个位置，针对该参考数据库生成差异，并将脚本提供给生产数据库团队。因此，我们发布到生产环境与我们的其他环境不同。
这使得运行版本化脚本的想法很有吸引力，因为我们在所有环境中使用相同的脚本，而且在部署过程中没有临时工作（例如手动恢复prod到参考DB）。但是，考虑到我们具有如此小规模的数据库情况，我觉得我们几乎不可能成为存在的DB工具的困难案例。我们想要的是尽可能简单易懂的东西。
像RedGate套件这样的工具是否适用于这种情况，或者我们应该使用版本脚本？成本并不是太大的问题，更多的是创建一个成功之坑，使维护和部署DB尽可能基本和自动化。