一般来讲常见的（小）项目开发，装一台数据库服务器，几个程序员用管理员身份在服务器上创建自己需要的表、存储过程，测试功能生成数据就什么都搞定了，后面数据库的维护管理都是越做越繁琐、发布越来越困难。好一些的情形会有专职的DBA来统一进行数据库相关的开发，但是更改脚本也是很难管理和生成。

　　数据库作为项目成果物的一部分，在这种情况下，是动态、变化的：

（1）对于数据库对象的变化，很难跟踪；

（2）对于开发过程中废弃的数据库对象，很难标识；

（3）由于测试数据的存在，很难将修改部署到不同的数据库副本；

（4）很难快速获取一个“空”的初始数据库；

（5）容易掩盖一些开发过程中引入的错误。

以上几点都是网上大家讨论总结出来的，对于我们公司来讲，由于一些初级程序员也涉及到数据库方面的更改和测试，有些技术方面需要关注和管理的知识是非常欠缺的（我们目前还没有专职DBA，窘～～），这时候我们只能是由有经验的程序员给予帮助和开发数据库的本地部署，相当浪费时间。

　　拿我们公司的问题出来做个说明，大家来看看，相信大家都遇到过类似的问题

　　（1）表结构和存储过程没有版本控制，无法确认修改者，无法跟踪业务逻辑变化。

　　（2）已经没用的表和存储过程残留在数据库里，但无法确认能不能删除。

　　（3）开发数据库上的修改，在不影响数据的情况下，同步到测试数据库很麻烦

　　（4）在开发中途需要给客户演示，于是要先把测试数据删除（但又要保留某些系统初始数据），获得一个“空”的初始数据库给客户安装。

　　（5）由于开发时的高权限造成了数据库对象依赖关系的错误，备份-恢复的部署方法是发现不了的。

　　网上有同僚说道：与其维护主数据库，还不如维护可在任何时间创建数据库的脚本，算是偶得——这与代码管理的概念同出一辙：

  • 确保所有数据库使用相同的对象
  • 总能从零开始创建一个数据库的副本
  • 可以捕获不再有效的对象
  • 可以使用源代码控制来管理脚本
  • 可以将数据库的创建工作集成到项目生成过程中以便快速捕获错误（可以是测试数据库）
  • 可以编写脚本将所需数据添加到数据库中，比如元数据
  • 可以编写用于单元测试的测试数据脚本

　　个人对数据库项目的定义：可用于持续集成的置于源代码控制下的数据库对象脚本集合。

　　检验方式：如程序源码一样，能够快速创建某个时间点的数据库。