數據庫的表設計簡介

   在數據庫的表設計上，根據業務需求應充分考慮 核心表與外圍表、配置表與事務表、日誌表與日結表、實時表與歷史表、事實表和維表等，兼顧數據的層次、安全、轉移、清理、擴展等機制。下面舉個實例簡單說明下。
    需求介紹：用戶打客服電話與座席通話結束後，系統對知足條件的通話記錄下發滿意度調查短信，共兩次交互過程，即通話結束後系統下發第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小時系統會是什麼影響啊。這種狀況下若是把須要增長的字段設計爲一個維表，豈不是更加方便，還符合了對錶垂直分割的原則。

 

   上面的只是針對業務需求人爲做出的劃分，本質上都是基本表，沒有什麼實質的區別。