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

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

tsp

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

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

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

Similar threads

S
【教程】QJSON 创建根结点为数组的 JSON 内容
回复
0
查看
510
swish
S
S
[流控] ZFlowControler 设计基本思想说明
回复
0
查看
739
swish
S
S
[教程]程序保存数据的防断电处理策略
回复
0
查看
911
swish
S
X
使用unidac 连接FB 3.0 （含嵌入版） - xalion
回复
0
查看
721
xalion
X
X
如何在unidac 中执行一次查询获得多个数据集？ - xalion
回复
0
查看
944
xalion
X
后退
顶部