过去的一个关于数据库设计的讨论，觉得有些价值，自己收藏起来

过去的一个关于数据库设计的讨论，觉得有些价值，自己收藏起来。

antonyup_2006 写道

hehe 我们现在的项目也是反向生成表结构 做电子商务方面的
怎么说呢 两种方法都接触过  对于一些前期已经把表结构都设计好了的(有dba参与)的 可能用先设计数据库 然后在根据数据库来建模会比较好 特别是比较大的项目 对于数据库的设计在项目设计中会靠前做好 ,而对于项目开始的时候,库没设计好 而开发人员已经开始设计了 annotation的方式也不错 在设计的时候建立bean的时候把关系建好 反向生成数据结构 但这里有个问题 不知道各位是怎么解决的 就是我们现在出现个情况就是在开发的过程中 每个模块的开发人员都自己设计相关的模块表结构 当涉及到交叉公用的表时候会出现冗余  这样对于整个系统的数据设计好象有点不够严谨.出现着情况的一个重要原因就是需求变化比较大 并且是策划驱动的(自己公司的) 而不是客户需求驱动的.

反向生成表结构，仍然是正向建模吧？需求变化比较大的情况下，原有的表不可能满足的，要么能通过增加表和字段解决，要么部分进行重构。表结构进行重构的过程中，如果系统已经上线，还要保留原来数据，数据需要重新组织。不知道你们的项目有没有遇到这种情况。

PowerDesigner数据库建模和修改模型。根据建模文件生成Hibernate Mapping和PO，只有一对一，多对一，一对多三种关系，多对多用一对多和多对一表示,生成DAO层包含CRUD方法和查询方法，查询基于DetachedCriteria构建（直接使用DetachedCriteria并不方便，需要辅助对象对其生成），摒弃Hql方式（不利于重构），因为一对多等关系已经在建模的时候很完善，所以无需Hql进行join查询，对于A一对多B，B一对多C，C一对多D这种情况，根据实际的查询情况增加A一对多C或B一对多D这样的冗余关联关系，节省计算量。

统计是个复杂的问题，总结了两大类，时间和空间型统计，如每个月的数据进行统计属于时间型，如A一对多B，统计属于某个A的多个B某些字段属于空间型。对于时间型，先设基本统计单位，如每日统计数据，在此基础上统计每周，每月，在月的基础上统计每年，逐级进行。一般时间型统计涉及数据表很广，涉及记录数多，一般系统初始化的时候预先统计一次放到内存，当数据库增加新记录的时候触发累加，只要累加的方法是线程安全的就行，需要统计的时候直接访问内存对象，速度很快，不用访问数据库。对于空间型的，如果涉及的数据量不多，直接使用Hibernate的Projection来做，如果数据量过多，则使用内存对象放中间结果。

数据模型的局部修正，通过工具很快就能对生成的JAVA代码进行重构，因为编译器会检查编译错误，只要修正错误即可。由于没有使用Hql，加上单元测试工具，不会因为重构产生很多陷阱。

比较麻烦的是旧有数据的兼容性。至今没有很好的解决办法，通常都是在数据库中建多一个备用的schema，把旧模型的数据转换之后拷贝过来（必须先停掉目标数据的constrains，否则会出错的），数据量很大的话会很麻烦。还有一个办法是把定期把旧数据移动到数据仓库，模型变动后不更改数据仓库旧数据的结构，把模型变动后的数据归档的时候将放到新的数据仓库当中。遗留数据的处理向来都是个麻烦的问题啊。