線上交易處理與決策支援的比較

資料庫應用程式可歸類成兩個主要的類別：

• 線上交易處理 (OLTP)
• 決策支援

這些應用程式類型的特性對於資料庫的設計考量具有很大的影響。

線上交易處理

線上交易處理資料庫應用程式對管理變更的資料來說是最理想的作法。這些應用程式通常有許多使用者會在變更即時資料的同時執行交易。雖然使用者的個別資料要求通常參考少數的記錄，但會同時發出許多要求。這類資料庫的常見例子為航空訂票系統和銀行交易系統。這類應用程式的主要考量為並行和不可部份完成性。

資料庫系統中的並行控制可保證兩個使用者不會變更相同的資料，或某個使用者不能在其他使用者處理資料結束之前變更部份資料。例如，如果您請航空訂票人員保留最後一個空的機位，該人員開始以您的姓名保留機位，這時候別的訂票人員就不能告訴其他旅客該機位仍是空的。

不可部份完成性保證交易中的所有步驟會以群組方式順利完成。若有任何步驟失敗，其他步驟也無法完成。例如，銀行交易可能牽涉到兩個步驟：從支票帳號中取出款項，並將它們放入存款帳號內。如果從支票帳號中移出款項的步驟成功了，就需要確認該款項已放入存款帳號內，或將它放回支票帳號內。

線上交易處理設計考量

交易處理系統資料庫應該設計成可提升下列事項：

• 良好的資料放置
  I/O 瓶頸是 OLTP 系統的重要考量，因為修改資料庫內資料的使用者很多。當您設計資料庫時，請判斷資料的適當存取模式，並將經常存取的資料結合在一起。使用檔案群組和 RAID (磁碟陣列) 系統來協助此議題。
• 較短的交易可減少長期的鎖定，並改善並行
  避免交易過程中與使用者互動。可能的話，請執行單一預存程序來處理整個交易。您在交易中參考資料表的順序將影響並行。在交易結束時將參考放在經常存取的資料表內可縮短鎖定的時間。
• 線上備份
  OLTP 系統的特徵為經常性連續作業，其中的關閉時間會保持為絕對最小值。也就是說，每天作業 24 小時，全年無休。雖然「SQL Server 2005 Database Engine」可在使用資料庫時備份它，您最好還是將備份程序的執行時間訂在活動量較低時，以降低對使用者的影響。
• 資料庫的高度正規化
  減少重複的資訊以增加更新的速度並改進並行。減少資料也可改進備份速度，因為需要備份的資料較少。
• 最少或沒有歷程記錄或彙總資料。
  不常參考的資料可歸檔至個別的資料庫，或從經常更新的資料表中移出，並放入僅含歷程記錄資料的資料表內。這可讓資料表儘可能縮小，藉此改善備份時間和查詢效能。
• 小心地使用索引
  每次加入或修改資料列之後都必須更新索引。為了避免針對經常更新的資料表過度製作索引，可讓索引小一些。使用 Database Engine Tuning Advisor 來設計索引。
• 較佳的硬體組態可處理許多同時使用者以及 OLTP 系統所需的快速反應時間

決策支援

決策支援資料庫應用程式適用於不會變更資料的資料查詢。例如，公司可根據日期、銷售區域或產品，定期地建立摘要的銷售資料，並將此資訊儲存於個別的資料庫內，以供進階的管理分析使用。在建立業務決策時，使用者必須能根據各種條件查詢資料，以快速決定銷售趨勢。不過，他們並不需要變更此資料。決策支援資料庫中的資料表將製作許多索引，並且經常會預先處理與整理原始資料，以支援要使用的各種查詢類型。因為使用者並不會變更資料，因此將不構成並行和不可部份完成性問題；資料變更只發生於定期的大量更新，並且時機為資料庫流量較低的下班時間。

決策支援設計考量

決策支援系統資料庫應設計成可提升下列事項：

• 製作較多索引
  決策支援系統的更新需求較低，但資料容量較大。您可使用許多索引來改善查詢效能。
• 將資料庫解除正規化
  引入預先彙總或摘要資料來滿足一般的查詢需求，並改善查詢回應時間。
• 使用星形或雪花架構來整理資料庫內的資料。