在数据库的表设计上，根据业务需求应充分考虑 核心表与外围表、配置表与事务表、日志表与日结表、实时表与历史表、事实表和维表等，兼顾数据的层次、安全、转移、清理、扩展等机制。下面举个实例简单说明下。
    需求介绍：用户打客服电话与座席通话结束后，系统对满足条件的通话记录下发满意度调查短信，共两次交互过程，即通话结束后系统下发第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小时系统会是什么影响啊。这种情况下如果把需要增加的字段设计为一个维表，岂不是更加方便，还符合了对表垂直分割的原则。

 

   上面的只是针对业务需求人为作出的划分，本质上都是基本表，没有什么实质的区别。