我擔心我不知道我在做什麼。數據庫設計 - 關於效率的問題（和一般設計質量）

1：

我有一個表稱爲ticket具有稱爲total柱。當總數更新時，我想保留它的記錄（舊總數等），所以我決定刪除total列並創建一個名爲ticket_total的表，其中列ticket_id,total和datetime（最近的當然是「當前」總數）。

或

2：

然後我意識到我會在後面想給我的客戶通過total，排序票或拉手聚集總數，等等。所以，我決定，而不是報告的能力將total列放回ticket，並在更新總數時直接更改total列，但首先創建一個ticket_total行作爲先前的total的記錄。

看起來版本2會非常高效，因爲我不需要儘可能多地查詢相關的ticket_total表，但是我想知道你的數據庫專家在那裏想什麼。我只是在學習數據庫設計，並擔心我永遠不會擅長它。

來源

2010-10-04 orokusaki

我會與選項2，你有建議。

只要確保您正在執行事務中的更新（票證）+插入（在ticket_total中）以確保維持完整性。

來源

2010-10-04 03:27:12 InSane

謝謝。我目前使用Django的'@ transaction.commit_on_success'來包裝創建兩個記錄的方法。你認爲＃2是一種「好」的數據庫設計實踐嗎？如果沒有，我有完全的靈活性來改變它。 – orokusaki 2010-10-04 03:29:55

我會讓ticket_total成爲視圖，而不是表格。我會創建另一個視圖ticket_current，在那裏我會根據最新日期過濾票證，即如果票證表在ticket_Id和datetime上雙重鍵入。如果不是，則不顧最後一部分。

來源

2010-10-04 03:26:38 JoshRoss

第二種方法更快，但如果要創建總計歷史值的報表，則應該有一個單獨的表格，您可以將要替換的值與時間戳一起存儲。這種類型的表被稱爲審計表。

來源

2010-10-04 03:36:48

謝謝格特 - 我不知道這是一個標準做法。這讓我感覺自己更好，知道我意外執行了一個標準:) – orokusaki 2010-10-04 03:43:16

回覆：「效率」 - 最好不要太擔心項目開始時的數據庫效率問題。不成熟的優化是避免常見的錯誤。

更好的是專注於您的需求和設計給他們。之後，您可以測試以查看性能瓶頸在哪裏並正在解決它們。對於較小的數據庫（成千上萬行），即使是「低效」查詢，如果今天的服務器和軟件經常變得非常快速，

保持簡單我建議你避免組合鍵和重載表語義，除非你真的有這個需要。

提案您有兩種類型的數據：當前票證信息和舊「總」值的歷史記錄表。

所以你的版本2將是首選。

ticket 
    id 
    field_a 
    field_b 
    total # current_total 

ticket_total # history of ticket total field 
    id 
    ticket_id 
    total 
    create_time

也「總」聽起來像的東西聚集。我建議你試着想出一個更具描述性的字段名稱。 - 場地總數是多少？「total_worktime」？

添加記得爲表添加索引。通過您用於查找的任何內容進行索引。例如，售票表是否有customer_id？確保它已被編入索引。

來源

2010-10-04 03:41:41

謝謝:)'total'確實聽起來相當通用，不是。特別是當考慮到表中有17列時。 – orokusaki 2010-10-04 03:45:20

數據庫設計 - 關於效率的問題（和一般設計質量）

1：

2：

回答

相關問題