过去的一个关于数据库设计的讨论，觉得有些价值，自己收藏起来 博客分类： PowerDesigner 数据结构Hibernate多线程电子商务单元测试
程序员文章站
2024-03-25 09:01:10
...
过去的一个关于数据库设计的讨论，觉得有些价值，自己收藏起来。
反向生成表结构，仍然是正向建模吧？需求变化比较大的情况下，原有的表不可能满足的，要么能通过增加表和字段解决，要么部分进行重构。表结构进行重构的过程中，如果系统已经上线，还要保留原来数据，数据需要重新组织。不知道你们的项目有没有遇到这种情况。
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，否则会出错的），数据量很大的话会很麻烦。还有一个办法是把定期把旧数据移动到数据仓库，模型变动后不更改数据仓库旧数据的结构，把模型变动后的数据归档的时候将放到新的数据仓库当中。遗留数据的处理向来都是个麻烦的问题啊。
antonyup_2006 写道
hehe 我们现在的项目也是反向生成表结构 做电子商务方面的
怎么说呢 两种方法都接触过 对于一些前期已经把表结构都设计好了的(有dba参与)的 可能用先设计数据库 然后在根据数据库来建模会比较好 特别是比较大的项目 对于数据库的设计在项目设计中会靠前做好 ,而对于项目开始的时候,库没设计好 而开发人员已经开始设计了 annotation的方式也不错 在设计的时候建立bean的时候把关系建好 反向生成数据结构 但这里有个问题 不知道各位是怎么解决的 就是我们现在出现个情况就是在开发的过程中 每个模块的开发人员都自己设计相关的模块表结构 当涉及到交叉公用的表时候会出现冗余 这样对于整个系统的数据设计好象有点不够严谨.出现着情况的一个重要原因就是需求变化比较大 并且是策划驱动的(自己公司的) 而不是客户需求驱动的.
怎么说呢 两种方法都接触过 对于一些前期已经把表结构都设计好了的(有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，否则会出错的），数据量很大的话会很麻烦。还有一个办法是把定期把旧数据移动到数据仓库，模型变动后不更改数据仓库旧数据的结构，把模型变动后的数据归档的时候将放到新的数据仓库当中。遗留数据的处理向来都是个麻烦的问题啊。