我们的现实情况是：开发部负责产品的开发，他们会根据需要修改数据库，对于数据库非常熟悉；工程部负责给给客户升级程序和数据库，对于数据库不属性，别指望他们直接修改表结构或触发器或存储过程；客户分布在天南海北，有的距离非常遥远。
我们的最新版本的产品在客户的数据库上不能运行，因为客户A的数据库太旧了。我们需要查看当前程序所能够支持的最新的数据库与客户数据库的差异，看客户的数据库中缺少那些东西，然后手工添加这些内容，最后经过几个回合之后，问题解决了，软件升级完成。
如果客户B反馈了一个新的需求，然后我们在产品中实现了，同时需要给客户B的数据库进行更新，需要添加一些字段，添加一些数据表，或存储过程，或触发器，或函数等等，我们往往提供一个傻瓜式的文档，交给工程师，然后在客户B哪里进行一系列的操作，才可以完成数据库的改进，最后才可以给客户更新实现了新的需求的程序。
客户C是个重点客户，他们的多数需求我们都必须尽可能快的实现，因此，上述的B的情况被大量的重复，这样的效率非常低。
有什么办法可以非常简单的实现客户数据库的升级呢？
关键是保证数据库与产品的一致致性。
数据库版本1－－－产品版本1
数据库版本2－－－产品版本2
数据库版本3－－－产品版本3
如果所有客户的数据库都是一样的，问题也比较容易，然而，往往所有的客户数据库都或多或少的有些差异，数据库的大部分是相同的，但是部分的细节可能不同。
- 处理相同的部分
经过比较所有的数据库和应用程序，我们发现，应用程序只依赖于各个数据库中相同的部分，而不依赖那些不同的部分。我们将那些所有数据库相同的部分之为公共部分，或者称之为系统数据库对象，不那些不同的部分称之为私有部分，或客户数据库对象。系统数据对象中那些表，字段，触发器，存储过程，函数，视图等等都保存在一个脚本文件中，我们称之为系统对象脚本文件，这个系统对象脚本文件根据程序的发布可以有多个不同的版本，具有如下的共同特征：
1、系统数据中所有的对象随着时间的增加只会增加不会减少。无论是数据表，字段，还是用户自定义存储过程或函数，只增加不减少。从而保证系统数据的兼容性。
2、最新的数据库可以保证所有版本的程序的正常运行。
3、系统对象脚本文和应用程序都采用同样的版本编号规则（年月日时分秒：的20080505093101，2008年5月5日9点31分01秒），任何版本的应用程序都可以运行在版本号大于或等于自己版本号的数据库上。
因此，如果我们将一个版本的应用程序归档到产品管理器中，则我们只需要接着将当前数据库（在公司有一个专门的数据库，是最新的，我们的程序都首先在这个数据库上调试）创建一个系统对象脚本文件，保存在数据库管理器中即可。
如果我们需要给某个用户升级应用程序，只需要下载一个与应用程序版本匹配的系统数据库对象脚本文件，然后到客户数据库上运行这个脚本文件，即可。
通过上述的这种方式，我们解决了系统数据库对象的在不同客户数据库上升级的问题。那么那些客户数据库对象如何升级呢？每个客户的数据库在这部分上差别太大了，如何通过一种简单的方式实现升级呢？
2. 处理不同的部分
首先我们来分析一下为什么客户的数据库会各不相同，这种差异是如何产生的，并且主要是那些差异？
第一次与众不同
当我们刚刚给用户安装新的应用程序时，性能很好，用户只提了一个要求，希望每份报告只打印一次，只有主任可以打印两次或更多次。为此，我们需要在数据表中添加一个字段”PrintedCount“，用于记录打印报告的次数，而且我们认为这种需求对其他的用户也是有价值的，因此我们把这个字段作为软件系统支持的一个基本特征，在我们公司的开发数据库上添加了这个字段，程序也开始依赖这个字段了。这个用户的数据库开始与众不同，因为其他的用户还没有这个字段。（为了保证新版本的程序在其他用户哪里都可以使用，我们在程序的代码中增加了”PrintedCount“字段的判断，如果字段不存在，则创建该字段，便于给其他用户升级程序时自动升级数据库）
第二次与众不同
一个月之后这个用户开始提出，希望在报告打印48小时之后数据自动归档，不允许任何人对报告进行修改。我们的解决方案是在客户的数据库中创建了一个存储过程，该存储过程可以实现对打印时间超过48小时，但是还没归档的数据自动执行归档操作。最后在服务器上添加了一个任务，每天晚上执行一次，调用刚刚编写存储过程即可。
第三次很多的与众不同
半年之后，用户提出要跟其他的系统做接口。这个比较复杂，需要我们在数据库中添加一个读取数据的存储过程，还有一个回写数据的存储过程，在数据表中添加多个字段。通过任务调用存储过程实现数据的读取和回写。如此一来，这个用户的数据库与其他用户的数据库非常非常的不同了。
其他的一些与众不同
由于需求不断的产生，这个用户的数据库有增加了一些其他的变化。
除了PrintedCount字段之外，其他的那些变化，没有必要告诉通知其他用户的数据库。程序中也不需要增加这种负担：在程序启动时额外的更新数据库对象，这些对象是对系统用户的数据库是没有任何意义的。
也就是说，我们没有必要在给客户升级程序时升级客户数据库对象，我们只需要升级系统数据库对象即可。
如果需要对客户数据库对象进行升级（在用户需求改变的情况下，或系统发现BUG），我们目前的做法是在直接将用户的数据库备份回来，然后根据需求调试用户当前客户有关的代码，修改客户的数据库，并且把这种修改记录下来（写到文本文件中），最后将测试完成的程序连同这个文本文件同时发送给工程部即可。工程部会根据文本文件修改数据库，最后升级程序。
因此，改进之后的工作流程应该是这样的：测试人员将程序测试完成之后，归档到产品管理器，并且设置客户的名称和ID（表明这是针对某个客户而发布的程序版本），然后针对用户最新的数据库创建一个系统脚本文件，这个脚本文件也归档到客户数据库管理器中。工程部只要根据客户的ID从这两个管理器中得到相应的程序和脚本即可。
脚本保证工程部没有必要在接触数据库的底层对象，只需要通过一个程序进行升级即可，这个过程不会产生人为的错误，效率高，升级方便。