文/itrust 出处/博客园
决定使用
Castle ActiveRecord来开发新的系统,基于面向对象的思想将数据库设计转化为对象的代码设计,就可以将程序的持续集成开发自然引入数据库开发。再辅以liquibase,数据库的持续集成开发就可行了,也解决了数据库部署的问题。同时在引入liquibase后,数据库版本管理以及部署和升级也就简化了。
1 开发方法使用领域驱动设计方法(Domain Driven Design)开发数据库,以面向对象的设计方法设计数据库表,具体方法包括:
- 直接设计数据库实体类,然后使用ActiveRecord创建数据库表
- 数据库表的一切属性(列类型、长度、约束、索引,表间关系等全部在实体类中设计)
- 数据库访问层基于实体类实现,业务逻辑优先选择数据库访问层通过代码实现,除此之外的在存储过程中实现
2 数据库开发架构
附件:
您所在的用户组无法下载或查看附件- 每个数据库开发人员必须在本地数据库实例上进行设计、编码和测试
- 持续集成服务器通过监视SVN服务器上用户提交行为触发持续集成过程,在基线数据库上验证、部署新的数据库结构
- 持续集成数据库上的基线数据库
- 其结构(包含数据库静态数据)为当前已发布系统的结构
- 只有持续集成过程能够修改基线数据库
- 开发人员只能通过持续集成过程来修改该数据库
- 开发人员可将基线数据库视为产品数据库,可通过将其与本地数据库进行比较得到数据库部署脚本
3 数据库开发流程3.1 本地开发流程
附件:
您所在的用户组无法下载或查看附件- 所有设计和测试都在本地数据库上进行
- 每一个访问层函数和较为复杂的实体类(如含外键关系)应有测试案例,必须通过测试
- 数据库部署脚本的生成
- 在有多人设计数据库时需注意及时获取SVN上部署脚本在本地执行,与基线数据库保持一致
- 使用liquibase对比本地数据库和基线数据库,生成部署脚本
- 注意:已发布的数据库部署脚本不可更改
3.2 持续集成流程
附件:
您所在的用户组无法下载或查看附件- 数据库包括两个CC项目:studio和trunk,都采用该流程
- 上图中任一流程发生错误都导致持续集成失败
- 通过数据库文档可查看所有数据库结构修改日志
4 编码原则- 放弃使用Sql Server的domain,rule,default等(rule和default在2005中不被支持)
- 使用ActiveRecord的Nested Data替代domain
- 通过对Nested Data所进行ActiveRecord定义实现rule和default
- 谨慎使用视图和存储过程
考量我目前的新系统开发,这个方法和流程还是可行的,估计在实践中还会有很多问题出现,希望发现问题的园友不吝赐教。
您可能对 [SQL] 的这些文章也感兴趣: