價格表的數據庫表結構

我喜歡約10個表，其中包含日期範圍和某些值屬於日期範圍的記錄。價格表的數據庫表結構

每張表都有一些含義。

例如

率

start_date DATE 
    end_date DATE 
    price DOUBLE

可用性

start_date DATE 
    end_date DATE 
    availability INT

，然後表日期

 day DATE

哪裏都是每天提前2年日期。

最終結果是將這10個表加入日期表。查詢需要更長的時間，因爲還有一些其他聯接和子查詢。

我一直在考慮創建一個包含所有10個表格數據的更大表格，但是最終表格會包含大約1.5M-2M個記錄。

從測試來看，它似乎更快（0.2秒而不是1秒左右）在此表中搜索，而不是連接表和搜索連接結果。

是否有任何真正的原因，爲什麼它應該是一個糟糕的主意，有一個與許多記錄表？

決賽桌看起來像

day DATE 
    price DOUBLE 
    availability INT

謝謝您的意見。

來源

2012-12-18 Douglish

這是一個複雜的問題。答案在很大程度上取決於使用模式。據推測，大多數價值觀不會每天都在變化。所以，你可能會大大增加數據庫的大小。

另一方面，像可用性這樣的東西可能每天都在改變，所以你的數據庫中已經有了一個大表。

如果您的使用模式一次集中在一張桌子上，我會試着說「保持足夠的安靜」。也就是說，如果沒有損壞，不要做出改變。如果您的使用涉及多種更新的某種類型的記錄，我傾向於將它們留在單獨的表中（因此鎖定一種類型的值不會阻止其他類型的查詢）。

但是，您的使用情況表明您正在合併這些表格。如果是這樣，我認爲每個項目每天放在一行是有道理的。如果您一次能獲得連續的日子，您可能會發現在基礎表中分開放置日子可以大大簡化您的查詢。而且，如果您的查詢專注於特定的時間範圍，則您提出的結構會將相關數據保留在緩存中，爲更好的性能留出空間。

我很欣賞波希米亞人所說的。但是，您已經進入了最低級別的粒度，並且看到它對您有用。我認爲你應該進行重組。

來源

2012-12-18 22:27:44

謝謝您的評論，我決定重組。 – Douglish

我一度走下這條路，後悔了。

事實上，您有數百萬行的投影告訴我，來自一個表的日期不與另一個表的日期對齊，導致爲某些屬性創建額外的邊界，因爲在一個表中所有屬性必須共享相同的界限。

我遇到的問題是，業務發生了變化，突然之間我有更多的組合需要處理，行數也隨之消失，顯着減慢了查詢速度。另一個問題是保持數據是最新的 - 我的「超級」表是從單獨的表中計算出來的。

我發現保持它們分離並將邏輯移動到應用層爲我工作。

我所處理的數據幾乎與您的數據完全一樣，除了我只有3個表：我有可用性，定價和保證金。事實是這三個是不相關的，所以日期範圍從未對齊過，在大表中租用大量人工行。

來源

2012-12-18 21:19:09 Bohemian

那麼，在我的情況下，所有的數據都是相關的，幾乎每個表格中都有一個記錄，最後我做了幾乎相同的巨大表格的連接，但是有一些條件減小了這個大小。類似於SELECT * FROM days LEFT JOIN rates ON rates.start_date> = day AND rates.end_date <= day LEFT JOIN availability on availability.start_date> = day AND availability.end_date <= day ... etc.我無法不要覺得這是多餘的，我可以將它們全部放在一張桌子上，但是放大一張。我只怕表演。 – Douglish

在這種情況下，我會將我的表格設計更改爲具有單個日期列而非範圍。即使這將意味着連續幾天的重複數據，連接速度也會更快，因爲連接是通過簡單的等於比較來完成的，而不是匹配之間的連接，特別是如果您在日期列中放置索引。這將保持您的數據模型的健全，並且仍然給您卓越的性能。 – Bohemian

價格表的數據庫表結構

回答

相關問題