2017-04-22 117 views
0

我有Stock表。數據庫,單獨的表或列用於額外的字段?

sku 
quantity 
quantity_sold 
price 
seller 

StockExtra表中的產品,具有日期/時間屬性(你能想到的賽事門票的)

stock # references stock 
quantity 
quantity_sold 
price 
date_at 
time_at 
datetime_rule # foreign key to another table, it is a rule that describes when events occur 

對於事件的門票,我用stock and seller從庫存表,但使用量從StockExtra表。因爲不同日期的票可以有不同的數量和價格。

我已經劃分了表格,但並不確定這是否是最佳做法。

現在我需要創建另一個表來保持獨立的市場的門店庫存數據。
(我正在製造一個系統,賣家可以在多個商店銷售產品時管理他的庫存)

例如,可以在amazon.com和ebay.com上銷售活動門票。 而每個商店的價格,數量可能會有所不同。

所以會有一對多的關係從StockStoreStock

Stock將持有的默認價格和數量彙總/ quantity_sold所有商店。 StoreStock將保存個別商店的數據。

由於相同的原因,我還需要從StockExtraStoreStock之間的一對多關係,即價格/數量可能會因事件票證的每個日期/時間而不同。

因此,以我目前的設置, 將有StockStockExtraStoreStock

即使與非票據產品的日期/時間相關的字段爲空,最好是隻有StockStoreStock

+0

@TimBiegeleisen我將股票字段添加到StockExtra。 (我的錯誤)「你可能過於複雜的事情。」請更具體一點,你是否暗示我應該合併Stock/StockExtra表格? – eugene

回答

0

你應該考慮通過以一致的方式藏在心裏,降低了系統的複雜性。將複雜場景與簡單場景保持在同一個表中。

通過保持在不同的地方相同的信息(例如Stock VS StockExtra,或Stock VS StoreStock)正在創建中,你的代碼必須有額外的分支找到視情況而定的數據的情況。

當你爲一個單一的交易數據後要去,分支是不是世界的末日,但它是更多的代碼有編寫,調試和維護。但是,當您追蹤數據合計時,將它分散到多個潛在位置,使得您的數據檢索太多更復雜。

我會建議保持一切在最詳細的水平。因此,即使只有一個商店適用於特定情況,一切仍在StoreStock之內。然後,除非您有明顯的性能問題,否則請勿從Stock中拆分StockExtra - 只需使用Stock中的可爲空的列即可。

可以保留默認價格Stock,但爲了維持代碼的下一個人,請使用更具描述性的名稱。我建議不要跟蹤Stock表中的銷售數量。只保留在StoreStock。不要保留預先計算好的數量。這將不可避免地出現問題。相反,跟蹤數量增加(收據)和數量刪除(銷售),並動態計算手頭的數量。這將避免庫存對帳問題。

相關問題