数据库的设计问题(50分)

  • 主题发起人 主题发起人 tsp
  • 开始时间 开始时间
T

tsp

Unregistered / Unconfirmed
GUEST, unregistred user!
  很多MIS系统中有这样的情况:第一,有很多子系统;第二,有很多数据需要进行本期、
累计以及上年同期数据的比较。现在有个问题:分别以SQLServer和Oracle为例,为了达到
程序处理方便快捷和数据分类明确两者的平衡,应该如何设计数据库?
  一种方式是:建立公用数据库以及各专业数据库,对某一个数据表来说,本年度数据和
历史数据放在一起。这样做的好处是求累计数据和同期数据非常方便,但缺点是经过一段时
间后,不经常访问的历史数据越来越多,影响了访问本年度常用数据的效率;
  另一种方式是:建立公用数据库和年度数据库,本年度数据和历史数据分开存放在不同
的年度数据表中。这样做的好处是系统经常访问的数据主要存放在本年度中,访问效率高,
分类清晰,备份方便,但缺点是统计累计和同期数据需要跨越多个数据库,程序设计较为复
杂。或者在此基础上设计另外一种方案是:以3-5年为一个时间段建立年度数据,但如果求
跨越两个时间段的累计或同期数据又是一个问题。
  第三种方式是:建立公用数据库以及使用单位数据库。比如说,总公司下面有分公司A、
B、C等,每个单位都要使用这套系统,但他们之间是没有联系的,那么如果要在总公司建库
的话,就建立公用数据库和A、B、C三个库,这三个库中放的是本单位的所有专业、所有年
份的数据,这样各自事务互不相干。但有一个问题就是,总公司在汇总数据时又遇到了麻烦。
  每次开始设计一个项目之前,我都要为这些问题费一番脑筋,请大家踊跃讨论,到底该
如何设计才是比较理想的呢?
  烦请赐教!
 
  
我的个人看法:

1、可以使用分立的单位数据库,只要在设计库结构时为数据汇总和联合查询适当的
  留出方便即可。一般说来,机制有很大差异的业务,其数据格式也有较大差异;
  相似的业务,其数据格式也很可能相似;相关的业务,其数据格式也很可能相关。
  因此应该能够比较容易的为汇总和联合查询创造便利条件。

2、至于数据量的年度累计问题,应根据具体业务类型来确定。值得注意的是,应重
  点考虑本系统的生命周期内的应用性能。原系统生命周期结束后,以前的数据一
  般只用于有规律的汇总操作和个别数据的调阅,一般不会再走入主业务流程。况
  且这时候软件也要升级了,数据格式一旦变更,老数据可能就要归档封存了。
  
 
同意 snowboat 说法.
 
数据仓库啦。。。。
业务系统的原始数据通过仓库或者集市来获取。做分析。。
 
在这个问题上我有一些不同的看法,我觉得你考虑这个问题的观点不对.
建立数据库首先你应该首要考虑数据和数据之间的关系,而不是业务之间的关系.考虑数据之间
关系的目的是为了作出最有效率的数据库,严格的说是数据表,以及表和表之间的关系.比如你所谓的
年度数据和历史数据,从数据上说,他们是相同的数据,那么,他们应该在一个表里,没有什么
历史数据表和年度数据表.
要表达业务的关系,有两种方式,一是在数据库端,用视图(推荐,个人认为比较好),存储过程
等数据库服务器的方法来表达业务逻辑.比如建立一个年度数据的视图,只取近一年的数据.
那么它什么时候都是近一年的数据,都不同调整.其实你上面所说的功能,可以说是企业的
[red]业务逻辑[/red],这些应该放在中间层或服务器上来完成,可以通过视图,存储过程
以及恰当的权限来完成.另一种报答这种业务的方式是在客户端程序来完成,这不推荐.
总之,个人认为设计数据库的数据表时,应不要过多的考虑业务需求,让数据表尽量的高效而
冗余小,而后,通过设计数据库的视图,存储过程以及权限等来设计业务逻辑.
 
  
to 子陵
  我个人感觉,数据库的设计不能理想化。因项目性质、规模、内容的不同,设计数据
库应灵活掌握。举个众所周知的例子:为了给编写SQL语句提供方便,设计表时可以有意增
加冗余字段,而不是到基本表里去查找。这虽然不符合范式,但在一些地方却是有益的甚至
必须的。回到tsp的问题上来,在考虑查询效率、存储量、编码难度、工期、成本等因素的
情况下,我觉得有些系统采用的看似“土”的设计实际上是实用的、是正确的。
  我的经验也不多,愿和子陵兄继续探讨。
  
 
如果是ORACLE就采用第一种方式,同时对数据进行分区,每一年在一个区。
 
我基本同意子陵的看法。snowboat所谓的编写SQL语句方便可能是指编写Select语句方便,
但其它语句可能就不方便了,因为你需要更多的语句来维护你的冗余数据。我的体会是:
只要表结构清晰,冗余越少,设计SQL越方便。
我与子陵意见不同的是:业务逻辑可以完全不依赖数据库,完全在数据库的客户端体现。
当然这个客户端也是服务器应用服务器。现在的数据库越来越轻松了。对于大部分使用
多层的体系来讲:数据库只是一个数据存贮器和数据审核器。
 
我的想法是对不同的月份采用不同的数据表,年度统计的用视图来做统计
我以前做的系统没有将数据分开来,现在就已经碰到麻烦了,
数据库大小到了2个g,有的时候数据处理还处理不了。
 
  我觉得全部按月份区分开来也没有必要,因为本身子系统就多,分支部门(应用单位)
也多,再按月份区分就使数据库看上去非常复杂。是不是按年份或按分支部门建立数据库?
 
补充一下,我的安月份区分数据的数据是对数据量比较大的那部分业务系统,而不是对整个系统用同样的策略
 
我的意见:
首先,对需要的数据进行分析,根据日常业务的相关程度、查询的频率等,然后分类存储这些数据,
例如设计一个当前库(存放当前业务相关程度很高的、查询频繁的数据,提高业务操作效率是其设计的主要目标),
历史数据库(归档存放历史上的数据,比如上年以前的、上月以前的、查询不频繁的数据,主要是满足各种复杂的查询和
和统计分析,满足上述要求是其主要的设计目标,这个库可能很大,应该采用数据仓库的方法来保存数据)。
其次,需要设计当前库转存到历史库的功能。
第三,重新设计查询,特别是跨库的查询。
关键:对数据进行区分,分别采用不同的存储方式。。
希望继续探讨!
 
同一楼上的。
如果你的数据量到了100万季的话,最好使用数据仓库,否则你吃不了兜着走。
 
To newman0816 & hpretty二位仁兄:
能介绍一下“节”和“数据仓库”的概念及其具体设计吗?因为这些名词我听说倒是听说
过一些,但实际的应用却没有见到过,它们同一般的数据库有什么区别呢?
 
不好意思,笔误!
关于数据仓库,我也是刚刚接触不久,具体的你可以参考数据仓库的书。
 
hpretty说的视图倒是很好。赞成。
 
后退
顶部