ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 表结构设计讨论

表结构设计讨论

原创 Linux操作系统 作者:husthxd 时间:2008-04-22 20:20:42 0 删除 编辑
--------- 上一个项目启动前对于表结构设计方面的讨论 ---------

1.      多个业务保存到同一张表

优点:

数据聚集度较高,代码量少

缺点:

1)      结构不清晰

2)      由于工作流只能支持单个业务,无法跟工作流结合

 

结论:采用第一种方案。

 

2.      更新修改业务

根据不同的业务类型,分为两类:

1)      显式修改,也就是系统需要提供界面修改信息的,比如单位基本信息修改、个人基本信息修改,建议采用统一的通用修改模块实现(该模块目前已实现85%)。可以达到的效果是:把修改信息作为一笔业务看待,何时修改、何人修改、什么原因修改、修改了什么字段以及原值是什么,新值是什么,一清二楚。

2)      隐式修改,即办理一笔业务,修改了其他相关表信息的,比如人员增减变动,办理停保业务,修改了个人基本信息表中的人员状态为“停保”。这时候的原始信息可以通过“历史数据的保留”讨论得出的方案保留。

 

结论:显式修改,采用通用修改模块修改;隐式修改,视具体的业务具体处理。

 

3.      历史数据的保留

两种方案:

1)      在业务表上加入“有效标志”字段,0-当前 1-历史 9-无效

优点:

Ø        java程序处理方便,只对同一张表操作,无需书写额外的代码

Ø        查询历史信息和无效信息只需要更改标志标志即可,通过持久层的封装统一处理

缺点:

Ø        后台查询不方便,加入有效标志=x,才能区分有效、历史还是无效记录

Ø        PL/SQL处理不方便,理由同上

Ø        对于存在业务主键(业务唯一性约束)的情况,要保证有效标志=0(当前)的情况下,保证唯一,目前Oracle有这样的机制实现,迁移到数据库,未确定使用数据库的机制是否可以实现

Ø        性能损失,a)在同一张表保留历史和无效数据,日积月累会降低查询当前记录的性能,尤其是对于频繁修改的表,很可能会况会出现历史数据+无效数据>当前数据的情况;b)降低使用索引的性能,对于某些存在业务主键的表,由于不能对全表数据建立业务主键上的唯一索引,只能建立普通索引,必然会导致性能的下降

Ø        数据量特别大的表情况,出于性能上的考虑,不太合适

2)      建立历史表,表结构跟原表一样,但需要加入

优点:

Ø        历史、无效数据和当前数据隔离,不存在性能降低的问题

Ø        可以在业务主键上建立唯一索引,不存在“有效标志”出现的问题

缺点:

Ø        对每张需要保留历史记录的表都需要建立历史表

Ø        java程序上的处理要对多张表操作,存在不够方便(是否考虑使用通用的一种处理方式?)

 

结论:采用第二种方案,对每张需要保留历史记录的表都建立历史表,命名方法为原表名+_BAK,加入xgr-修改人,xgsj-修改时间,scr-删除人,scsj-删除时间四个字段;持久层在修改和删除表数据的时候保留历史、无效信息,并且提供查询历史、无效数据的接口。

 

4.      支付账目的设计

有两种设计方法:

1)      主从表:从表保存明细项金额,主表保存汇总金额和状态信息

优点:

Ø        灵活,明细项有增加减少变化时,相应的从表增加减少记录,对表结构没有影响

缺点:

Ø        数据量较大,比如在冲销的时候,明细信息也要同时冲销,可能会存在性能问题

2)      单表:

优点:

Ø        数据量较第一种方法要少

缺点:

Ø        不灵活,明细项增加减少时需要增加减少字段

 

结论:采用第一种方案。


来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/6906/viewspace-247758/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
ITPUB数据库版块资深版主,对Oracle、PostgreSQL有深入研究。

注册时间:2007-12-28

  • 博文量
    1542
  • 访问量
    4108962