0

我有两台安装了 SQL Server 2008 的服务器机器（一台用于开发，另一台用于客户端）。每当开发人员对开发服务器中的表/视图/存储过程进行更改时，它也需要反映客户端服务器。

目前，我正在手动处理所有更改，例如表中的新列、存储过程中的更改等。数据库脚本或复制可以为我自动化整个过程吗？或者是否有更好的解决方案来保持数据库模式的一致性。

帮助将不胜感激。

谢谢！

4

3 回答 3

1

我强烈建议创建一个环境，其中所有架构更改都完全通过 SQL 脚本完成 - 在任何环境中都不要“手动”。每个开发人员都必须将与他/她的错误修复（或新功能）相关的脚本提交到版本控制系统。

通常你会有一个从头开始创建数据库的大脚本和一个用于每个版本升级的脚本（从 1.0 到 1.1，一个从 1.1 到 1.2，依此类推）

如果您有人力，为每个版本维护一个“从头开始”脚本也非常方便。您是否需要它取决于在空系统上安装的频率。

我们在使用 Liquibase 来维护这一切方面拥有非常好的经验。它会自动跟踪哪些补丁已应用于数据库以及哪些补丁需要在升级期间运行。它还可以防止您两次运行相同的迁移。

于 2012-04-18T12:38:28.070 回答
0

所有数据库应用程序都存在的问题，并且很难解决。这样的解决方案无法计划，因为开发人员所做的更改需要首先进行测试，而且您当然不希望未经测试的代码与您的实时数据库合并。我对这个问题很感兴趣，因为我目前正在编写一个通用的解决方案来一劳永逸地解决这个问题。

但与此同时，我们正在使用一个名为 Open DBDiff 的开源产品（谷歌它 - 你不能错过它），它可以做一些改进，但效果很好。您将源数据库和目标数据库传递给它，它会生成一个脚本以使目标与源相同。复制程序集和用户角色似乎确实有些麻烦，但是对于所有事情，我都没有遇到任何麻烦。

于 2012-04-18T10:22:03.033 回答
0

我相信在确保更改已经过测试并正确检查到源代码控制之后，应该由人来进行部署。这不是完全自动化的东西。

人类应该使用这些工具。我使用 Visual Studio 2010 Professional，它具有强大的架构比较工具、生成和执行部署脚本并具有源代码控制集成。

于 2012-04-18T11:43:01.877 回答