Sql server 跟踪客户端中安装的sql server 2008数据库结构以便下次升级的最佳方法

我们公司有一个在Asp.net和Sql Server 2008中开发的与人力资源管理相关的产品，它安装在20-30个客户机上。由于每个客户的需求，软件都在不断开发中

现在，当进行一些新的更改时&一些使用旧版本的客户端要求进行一些更改，那么我们必须安装具有最新数据库结构的最新版本代码。现在我们必须用查询来升级他们的数据库&我们必须跟踪每个客户机数据库结构，以便生成升级查询

---

目前，我们正在存储每个客户机数据库&我们使用诸如Red Gate sql Compare之类的工具生成要升级的sql。随着客户数量的增加，这个过程变得非常乏味，那么这个过程的替代方案是什么，我们是否可以使用数据库版本控制或任何其他替代方法，使用installaware之类的安装程序，使用最新的数据库引用自动更新客户端数据库？

我怀疑您是否能找到一个最佳答案，因为有许多方法可以实现您的目标，但我可以分享我们的过程，以及我在过去10年中所获得的一些见解。也许他们会帮助你找到一个适合你的解决方案

首先，更新客户端数据库是一个困难的问题。自从您安装了软件后，您永远不知道他们会对数据库做什么。我让客户向我们的系统表添加他们自己的表、视图甚至索引，因为他们认为系统需要它们。所有这些都会在升级目标数据库时带来麻烦，因为您不一定知道数据库的状态

第二，我喜欢你最初的想法，安装程序升级数据库将是一种方式。然后我开始更多地思考这个问题，在我们的案例中，至少DBA通常不是升级前端软件的人。我们还从许多客户那里听说，在服务器上安装任何东西对他们来说都不是一件容易的事，所以回到原点

最后，我们选择构建自己的可执行文件，其中包含用于升级的脚本以及DBA\最终用户连接到服务器\数据库并运行升级过程的能力

（在我们的例子中，我们使用了大量加密存储过程，其中包含我们专有的商业智能，这就是为什么我们不只是让客户端可以使用脚本。）

如果您还没有这样做，请将您的数据库放入源代码管理！VisualStudio和RedGate都提供了促进这一点的产品。我两者都用过，并没有特别的偏好，但我想说的是，使用你和你的团队都喜欢的东西

当我们准备发布更新时，我们将在源代码管理中执行从数据库的最新版本到数据库的早期版本的差异。我们寻找任何新的对象和任何更改过的对象——我们很少删除对象，但这可能也是您需要的

一旦我们知道数据库中发生了什么变化，我们就会非常有条理地通过变化列表创建脚本来执行必要的变化。这是一个非常繁琐的过程，但它有助于确保客户具有轻松的升级体验。从本质上讲，我们对这个过程所做的是防御性编程，而不是假设数据库中存在表、视图、存储过程、函数等，我们首先检查以确保该项存在。如果是这样，我们就可以完全跳过DDL语句。在其他情况下，我们可能需要删除对象并重新创建它

明确地说，我们从不删除表，但我们通常会删除其他对象并重新创建它们，以确保对象是最新的

脚本以正确的顺序打包到我们的可执行文件（我们内部构建的解决方案）中（例如，如果您要添加一个表和一个引用该表的视图，则需要在视图之前创建该表）

顺便说一句，RedGate现在为您提供了一个这样做的工具，尽管我个人还没有在生产中使用过它

一旦我们感到满意，更新已经正确打包，我们就会尝试破坏它！我们在我们支持的所有SQL Server版本（例如2000、2005、2008、2012）上针对我们数据库的所有版本进行测试—真正的旧版本、我们以某种方式修改过的数据库。如果我们发现一种情况不起作用，我们会在它起作用之前修复脚本

我还应该提到，我们的数据库模式有一个日志表，我们的更新模块写入该日志表，以便记录何时执行更新、谁执行更新以及哪些对象是该更新的一部分。这有时有助于排除故障

虽然我们的实用程序在执行脚本之前没有备份数据库来升级，但我们建议您将此视为进程的一部分。（我们的文档强调了这一点的重要性，我们多年来与之合作的大多数DBA也很自然地做到了这一点，因此我们觉得没有必要将其写入实用程序）

数据库更新实用程序与我们的软件更新一起打包，并作为整个产品的另一个组件分发，可由在客户端站点的数据库中具有适当凭据和权限的任何用户执行

---

虽然这一过程多年来对我们很有效，但随着新工具引入市场，以及我们遇到客户遇到的错误，我们将继续完善这一过程。开发一个有效的过程可能需要一段时间，所以在任何给定的时间，尽量不要吃得太多。对我们来说，在源代码管理中获取数据库是最大的关键。一旦我们做到了这一点，事情就开始一次到位。

考虑支持导出/导入功能

“导出”功能