在数据库的表设计上,根据业务需求应充分考虑 核心表与外围表、配置表与事务表、日志表与日结表、实时表与历史表、事实表和维表等,兼顾数据的层次、安全、转移、清理、扩展等机制。下面举个实例简单说明下。
需求介绍:用户打客服电话与座席通话结束后,系统对满足条件的通话记录下发满意度调查短信,共两次交互过程,即通话结束后系统下发第1条短信,用户第1次回复;系统根据用户回复的短信下发第2条短信,用户第2次回复;系统根据回复的第2条短信下发第3条短信,流程结束(当然你也可以1条都不回复,但并不影响数据的转移)。
设计的部分对象见下:
--核心表
t_pub_commoninfo --记录座席与用户通话信息
t_pub_commoninfo_2 --结构同上,专门用于满意度调查
--配置表
t_scesmslot --判断满意度调查的总开关表
t_scesmscommandlist -- 判断满意度调查地市开关表
t_pub_citytelcode_night --夜间用的满意度调查地市表
t_scesmspolicyset --短信下发抽取策略表
--事务表
t_sms_commoninfo --记录满足条件的满意度调查数据
t_scesmsinfo ---满意度的下发记录
t_scesmsinfo_2 ---满意度的交互记录表
--历史表
t_scesmsinfohis --满意度的历史数据表
--存储过程
P_scegetsmsinfo_new --获取短信的存储过程
P_SCESendSMSLog_new --创建2,3条短信日志记录的存储过程
P_SCEReceiveSMSLog_new --回收短信存储过程
P_scesmstimeoutset --超时时间设置存储过程
P_scesmsinfo_transfer --数据转移的存储过程
P_scegetfirstsmsinfo --获取第一条调查短信的存储过程
P_dz_scesmsinfohis --转移数据到历史表的存储过程
--数据的产生及转移流程:
用户打客服电话---> ...---> 写数据到t_pub_commoninfo
---> p_ag_neworupdatecommoninfo 取数据到 t_pub_commoninfo_2
---> p_ag_SatisfactionResearch 取满足下发条件的数据到 t_sms_commoninfo
---> p_scegetsmsinfo 取第1条短信下发数据加到 t_scesmsinfo 表
---> 短信发送后,通过 p_scesmsinfo_transfer 转移到 t_scesmsinfo_2 中(记录2次的交互记录)
---> 然后通过 p_dz_scesmsinfohis 再转移到 t_scesmsinfohis 中
---> 1年后的数据转到磁带库。
此设计的优点:数据的转移层次分明、可以在表级实现I/O的部分分离、数据清理简单。缺点:代码复杂。
日志表与日结表:
日志表不用说了,记录每天的业务数据,日结表就是对日志表的每天分类汇总。如果发现某天的日结有误,可以删除数据重新日结。备份时只需要备份日志表,可以节省时间和空间。在报表开发中大量使用。Oracle的试图 v$sqlarea 可以看作是对v$sql 的分类汇总。
事实表和维表:
常用于BI等分析系统中,但OLTP系统中照样可以使用。
例如,某客户公共信息表存放了大量的数据,某需求需要增加字段,按常规做法是修改表结构,但是这样做要同步修改大量的使用此表的相关代码,容易出错,如果表中有几千万的数据,半个小时都难编译成功,这样对于7 X 24小时系统会是什么影响啊。这种情况下如果把需要增加的字段设计为一个维表,岂不是更加方便,还符合了对表垂直分割的原则。
上面的只是针对业务需求人为作出的划分,本质上都是基本表,没有什么实质的区别。
转载于:https://blog.51cto.com/srsunbing/1285401