最好有一個布爾（重要標誌）像一個屬性或在一個單獨的表？

我有三個案件，我不知道什麼是對每一個更好的解決方案，但都是關於布爾屬性最好有一個布爾（重要標誌）像一個屬性或在一個單獨的表？

我有一個鏈接表和各個環節都有屬性，以確定是否被訪問，破碎或過濾，每個值必須更新一次（除了重新設置所有的罕見情況）。
上面的相同鏈接具有不斷更新的訪問屬性，但在具有超過100萬行的表中，最多10,000或20,000個將是真實的。
我有一個頁面和一個屬性來表明是否每個處理或不。最後（處理後），所有行必須爲真。

我想知道什麼是這些情況下每個更好的解決方案。

我認爲是：屬性在第一種情況下，表在第二種，我不知道第三種。

另一種解決方案（如索引，也許）是受歡迎的。

重要提示：這兩個表（頁面和鏈接）可以有超過一百萬行。

來源

2011-07-16 Renato Dinhani

很難說出你真正在這裏問@Renato。三個重點是構建數據庫模式的三種可能方式嗎？第一個項目符號似乎將一個「鏈接」描述爲具有三個狀態，第二個和第三個似乎將鏈接描述爲只有兩個，所以在每種情況下都不代表相同的數據？ – Ben

事實上，如果你將三種情況分解成單獨的問題，你可能會更好，因爲它們似乎都在詢問在不同情況下哪些性能最高。拆分可以幫助你更清楚地解釋每一個，理想情況下用一些示例SQL來創建你所描述的表。 – Ben

該鏈接有四個狀態，三個描述在firt項目中，四個在第二個項目中，第三個是關於另一個表中具有另一個屬性的頁面。 –

沒有「最好」的方法。要知道你的方法是否具有足夠的性能，唯一的方法就是去做並看看。存在大量讀取和少量更新的情況下，持續更新的一種方法不會執行相同的操作。

我建議你把所有東西都放在桌子上，除非你有理由不要這樣做。

但最重要的是：什麼DBMS？

來源

2011-07-16 21:51:33 eaolson

添加了標籤，它是PostgreSQL –

我會說第一個案例的列，第二個的列和第三個列。

根據數據庫的規模，您的主要關注點可能是將經常更新的數據與大部分其他數據分開。這就是爲什麼我會爲第二種情況建議一張桌子。但是，您可以明智地使用PostgreSQL的「HOT」功能，這意味着如果更新的列是而非已編制索引，則更新不會導致表膨脹。但是，由於可能需要較長的搜索時間，保持自動清理快樂等因素，所以保持流量遠離大型表格可能仍然是一個好主意。如果您擔心，我會對此進行測試。

來源

2011-07-17 18:01:35

最好有一個布爾（重要標誌）像一個屬性或在一個單獨的表？

回答

相關問題