資料庫設計中一個沖突:資料庫外鍵 你用還是不用(2) 繼續....

上篇的反方觀點主要專注提取資料性能上問題比較突出:" 在海量的資料庫中想都不要去想外鍵，試想，一個程式每天要insert數百萬條記錄，當存在外鍵限制的時候，每次要去掃描此記錄是否合格，一般還不止一個字段有外鍵，這樣掃描的數量是成級數的增長！"

針對目前的這個派單系統資料當量較大的特點. 暫且把這個主外建涉及其他影響因素都排外. 本篇主要專注讨論于在主外鍵關系下提取資料的性能問題. 早上看到上篇的評論後做了一個小小的猜想.設計如下:

設計中設計到四個表:

Order【派單表】-主表, 其中設計三個外鍵分别為:表ConfirmState對應ConfirmId外鍵,  表OrderState對應orderstateid外鍵, 表SystemUser對應uid外鍵

說明一下這四張表在系統中的資料特點:

Order【派單表】為系統核心實體,且是系統設計中用藥頻繁操作的表,每天資料更新次數較多, 但每次更新的資料量不定,總體資料當量偏大.

ConfirmState【狀态确認表】為确認狀态實體, 隻有兩個字段:主鍵和狀态 狀态涉及到資料:【 已經完工/未完工】 資料量基本更新的幅度和頻率 較小. 屬于系統級别的配置.

OrderState【訂單處理狀态表】為訂單處理狀态标注實體, 隻有兩個字段:同上, 狀态中設計到五個字段:【申請/稽核/進行中/已解決/未解決】特點同上

SystemUser【系統使用者】系統使用者為公司一個部門的員工, 資料量偏小,且設計到系統使用者趨于一種穩定趨勢發展.

其實如果細心應該能夠發現對派單處理其實較為穩定流程來保證的，是以這點上用工作流WF來處理.

關系圖如下:

<a href="http://blog.51cto.com/attachment/201201/153650613.png" target="_blank"></a>

首先分析一下:對于系統的核心實體Order派單表, 業務中每天資料頻繁的增加,同時按精确日期及具體分類聯合查詢提取特定資料.等對資料的操作.在上文評論很多人都強調了對外鍵引用的表資料不宜較多，會出現一個性能與使用者體驗反應上一個"時間真空區". 這是一大弊病. 是以對于海量的資料外鍵引用，單單的從性能上講我在原則上是同義上文反方的觀點.

目前情況是三個外鍵資料量偏小,且資料變動可能性較小 總體資料是在系統級别的配置趨于穩定趨勢.如果這樣加以變動.

(1)引用時外鍵表一個穩定字段而非主鍵ID，在設計中我們解除這種實際資料庫中表與表之間的主外鍵依賴, 轉化到業務邏輯程式中加以控制.

(2)同時又能保證提取資料時能夠提取到準确的資料,(當然有可能性能提高幅度不是太明顯) 解除後圖:

<a href="http://blog.51cto.com/attachment/201201/153657236.jpg" target="_blank"></a>

上午做了一個資料提取執行個體我用CodeTimer測試一下取一千條資料，對比一下和昨天晚上相差不大:

Time Elapsed:   19,304ms                              Time Elapsed:   14,221ms

        CPU Cycles:     22,475,810,124

        Gen 0:          2051

        Gen 1:          0

        Gen 2:          0

        CPU Cycles:     16,554,201,551

        Gen 0:          2247

性能上還是沒法保證.

本文轉自chenkaiunion 51CTO部落格，原文連結:http://blog.51cto.com/chenkai/765294