2010-12-15 38 views
2

關於Web應用程序數據庫的實現,哪一個最好:只有裸露信息的精簡和非常小的數據庫,以及「重新計算」所有應用程序次要信息,根據需要,基於那些基本的,或者,一個數據庫充滿了所有那些以前已經計算過的次要信息,但可能過時了?2關於數據庫開發中的哲學和最佳實踐的問題

很明顯,這裏有一筆交易,我想任何人都會說這個問題的最佳答案是:「依賴」或「是兩者之間的混合」。但我真的不舒服或有足夠的經驗去獨自解釋這個問題。有人可以分享一些想法嗎?

此外,另一個不同的問題: 數據庫應該是特定時刻的「快照」,還是數據庫應該累積前一次的所有信息,以便回溯發生的事情?例如,假設我正在模擬一個銀行賬戶。我應該只保留當天的餘額,還是應該保留所有的交易,並從這些交易中推斷餘額?

這種東西的任何指針,在某種程度上,在數據庫設計中更深層次?

謝謝

+5

提問2個問題時,請考慮發佈2個問題。 – DwB 2010-12-15 13:38:14

回答

3

我的快速答案是將所有內容存儲在數據庫中。 當談論超大規模應用時,存儲成本遠低於處理成本。在小規模應用中,數據會少得多,因此存儲仍然是一個合適的解決方案。

大多數RDMS在處理海量數據方面非常出色,所以當有數百萬/萬億條記錄時,數據仍然可以相對較快地提取出來,這對於每次手動處理數據都無法說明。

如果您選擇計算數據而不是存儲數據,則處理時間不會像數據大小一樣增加 - 數據越多 - 用戶越多。這通常意味着處理時間將乘以數據的大小的用戶數量。

processing_time = data_size * num_users 

爲了回答您的其他問題,我認爲這將是引進一個特定時刻的「快照」,只有當數據量達到如此高的值,它的處理時間將會顯著最佳實踐

在計算大額金額(如銀行結餘)時,最好將任何繁重計算的結果及其日期戳存儲到數據庫。這只是意味着他們不需要重新計算,直到它變得過時。

0

您已回答了您的問題。

您所做的任何選擇都取決於應用程序的要求。

有時候速度會贏,有時會贏得空間。某些時候數據的準確性會勝出,有時快照贏了。

雖然您可能沒有能力說出重要的事情,但您解決問題的人應該能夠爲您解答。

1

我說開始只是跟蹤你所需要的數據,並在飛行中進行計算,但在整個設計過程,並順利進入試/生產軟件的記住,您可能需要切換到存儲在某個點預先計算的值。如果需要的話,設計能夠移動到該模型。

添加預先計算的值是聽起來不錯的事情之一(因爲在很多情況下,它的好),但可能不需要。保持設計儘可能簡單。如果在執行計算時性能成爲問題,那麼您可以將字段添加到數據庫中以存儲計算結果並在一夜之間運行批處理以趕上並填充遺留數據。

至於銀行的比喻,絕對存儲所有交易的完整記錄。存儲任何相關的數據。數據庫應該是過去和現在的數據存儲。審計追蹤等等。「當前狀態」既可以即時計算,也可以保持在一個平坦的表格中,並且在寫入其他表格(觸發器對此類事物有好處)期間重新計算,如果性能需要的話。

+0

當你有兩個相反的設計選擇並且選擇一個時,期望一旦你達到測試或者生產階段,你可以切換到另一個設計是否容易或者現實?我在這裏和那裏閱讀了這樣的建議,但是我不確定是否在非平凡的項目中確實是可能的。 – Cratylus 2010-12-15 13:57:46

+1

@ user384706:以後應該始終可以改變設計的各個方面,特別是在非平凡的項目中。您可以預測應用程序在生產中的表現如何,但最終只是猜測。改變業務需求,預料不到的環境變化,擴大規模以適應增長等。如果代碼和/或數據的設計如此複雜以至於改變它是一個荒謬的概念,那麼它從一開始就設計得不是很好。軟件將發生變化,從一開始就爲變化做好準備。 – David 2010-12-15 14:02:25

+0

@ user384706:另外,這兩個選擇並不真正「相反」。預先計算的數據可以很容易地添加到現有的數據審計跟蹤中。至少,這是我過去的經歷。如果這個特定的項目有一些微妙之處,那麼難以傳達。 – David 2010-12-15 14:03:31

0

我喜歡動態編程(不計算任何東西)。如果您的空間不受限制並且數據有點過時,那麼可以預先計算並存儲在數據庫中。這將爲您提供運行健全性檢查並確保數據始終一致的額外好處。

但正如其他已經回答,它取決於:)

+1

不需要它過期...觸發器,物化視圖或查詢緩存可以使其保持最新狀態 – 2010-12-15 17:43:50

1

這取決於:)因爲它使您能夠實現針對它的約束和其他邏輯數據庫堅持得出的數據是有用的。它也可以被索引,或者你可以把計算放在一個視圖中。無論如何,試着堅持Boyce-Codd/5th Normal Form作爲數據庫設計的指導。與您有時可能會聽到的情況相反,標準化的確如此,而不是表示您不能存儲派生數據 - 這僅表示數據不應該從同一個表中的非關鍵屬性派生。

從根本上任何數據庫是在特定時間點的已知事實的記錄。大多數數據庫都包含一些時間組件,一些數據被保留,而另一些則沒有 - 需求應該規定這一點。

2

沒有理由有過時的預先計算值。這就是觸發的原因(除其他外)。但是,對於大多數應用程序,我不會開始預先計算,直到您需要。這可能是計算速度始終存在。現在在銀行應用程序中,您需要幾乎立即從數千甚至數百萬條記錄中預先計算,是的,設計一個預先計算過程基於觸發器,每次更改時都會調整這些值。

至於是否存儲在時間上還是歷史價值只是一個畫面,那在很大程度上取決於你存儲的東西。如果它與財務數據有關,請存儲歷史記錄。當您接受審計時您將需要它。順便說一句,設計存儲一些截至行爲日期的數據(這不是非規範化)。例如,您有訂單,不要依賴客戶地址表或產品表來獲取有關產品運送到何處的數據或訂單發生時的成本。這些數據會隨着時間而變化,然後您的訂單就不再準確。您不希望您的財務報告改變售出的美元數量,因爲價格在6個月後發生變化。

還有其他的東西可能不需要被歷史存儲。在大多數申請中,我們不需要知道你是兩年前的Judy Jones,現在是Judy Smith(HR申請通常是一個例外)。