我們有一個與銷售相關的項目。數據庫設計？
現在我們將產品的庫存保存在一個名爲Stock的單獨表格中。在銷售，銷售退貨，採購和退貨時，庫存表將被更新。它運作良好，但在我們刪除或修改銷售或採購之一時，維護庫存更加困難。
我告訴我的老闆，我們不想把股票保存在一個單獨的表格中，而是寫一個函數來計算相關表格中的股票（sales,purchase，...）。每當用戶想知道股票時，他們都會很容易地調用該函數來獲取股票。因此我們不需要考慮庫存維護。我認爲它是一個好主意。
但他告訴我，如果有很多記錄會來，這個函數將需要更多的時間來執行，並且會降低軟件的效率。我不知道這是否正確。我知道的一件事是它反對DB的規範化。我們不需要將計算的值保留在表格中或表格外部。
我怎麼設計這個數據庫？是不是單獨的Stock表更好？
關於該主題here，由艾倫布朗提供了一個很好的研究。
一般來說，最好有一個規範化的數據庫。如果你有數據重複，而且有一天軟件不能正常工作，那麼你最終可能會得到不一致的數據，這對任何人都沒有好處。
對於大多數用途而言，您可以根據您的建議使計算足夠高效，以便您可以對原始數據執行計算。如果這對您的特定項目的可伸縮性確實存在問題，那麼可能最好有一個包含計算值的表格。這絕不會被視爲原始數據，並且可以在任何時候重新計算。那麼你的數據是安全的，並且你的計算速度很快。
另一種方法是根據你的DBMS來考慮一個視圖。
您的庫存表的內容是什麼？你是否有不同的庫存可以放置同一種產品？如果只有一隻股票，我會建議單獨的表格或計算的股票。計算庫存可能非常複雜且耗時，尤其是如果您的查詢比查詢更頻繁。然後，您應該將庫存量作爲產品表的一部分。
一般而言，您希望更多的規範化來保持數據完整性，並且這也趨向於針對數據更新進行優化（您不需要在多個位置更新同一條信息）。唯一的例外是如果您的數據庫將主要用於報告，並且只是偶爾更新。然後，由於您在報告時不需要從許多不同地點獲取信息，因此在幾個不同的地方進行更新的成本（因爲您是非規範化的）會得到報酬。
如果您的數據庫必須快速進行交易（更新），並且只是偶爾進行報告，則儘可能標準化。以這種方式保持所有數據的一致性也更容易。但是，如果你只是偶爾更新，而且主要是報告（即閱讀，或只是將數據從數據庫中提取出來），那麼你的老闆可能是對的，這可能是一個更好的選擇。但是，處理錯誤條件和保持數據完整性會更復雜（您必須更多地考慮什麼是「邏輯事務」，以及什麼時候出現錯誤時何時退出到目前爲止所做的所有更新）。
你有沒有想過使用觸發器來更新庫存表？
在一個完美的世界裏，所有變化的總和等於當前的庫存物品數量。在現實世界中，變化的總和更多的是對庫存物品數量的統計預測。如果你想讓現實世界變得完美，你必須考慮到這個數字中所有可能的變化。因此，除了購買和銷售之外，您還需要初始庫存的交易類型，盜竊，自然災害，捐贈給紅十字會等。如果預測變量和實際項目數量出現一些不可預見的情況，您需要虛擬交易來糾正計數原因。所有這些都會干擾你的交易表。
你老闆的表現論證也是有效的。每次您需要庫存物品的數量時，您必須彙總所有交易。如果你有很多這樣的數據庫，那麼即使你正確地爲事務處理表建立索引，你也可以從索引中獲得總和，這可能會成爲性能瓶頸。
並不完全同意庫存表違反正常化。您現在有庫存的物品數量以及購買或出售的物品數量在概念上並不相同，它們是不同的數字，這些數字恰好與您的業務採購和出售它們的業務規則相關聯（而不是比製造並捐贈給紅十字會），並且如上所述，它們只在完美的世界中完全相關。