我應該爲重複值（varchar）使用單獨的表嗎？

我有一張表，其中每秒添加3行數據，並且我打算保留大約30M行。（舊數據將被刪除）。我應該爲重複值（varchar）使用單獨的表嗎？

我需要添加一列：varchar（1000）。我無法預先知道它的內容是什麼，但我確實知道它會是非常重複的：數千行到數百萬行將具有相同的值。它通常大約200個字符長。

由於數據被使用存儲過程我看到兩個選項

添加一列VARCHAR（1000）
創建一個表（INT ID，VARCHAR（1000）值）內StoredProcedure的加入，查看該值是否存在於其他表中或創建它我希望這個其他表始終具有最大值100。

我知道這兩個選項之間的一些折衷，但我很難在這個問題上下定決心。

選項1較重，但我得到更快的插入。需要更少的連接，因此查詢更簡單。選項2較輕插入需要很長時間，但查詢有可能會更快。我認爲我更接近正常的形式，但是我也有一個有一個有意義的列的表。

從我給你的信息看，哪個選項好看？（你也可以想出另一種選擇）。

來源

2011-12-08 Benoittr

這個新列中會有很多NULL值嗎？您是否需要根據此列的內容搜索大型表格？另外，表格已經有多少個字符？ – Sparky

你正在使用哪個版本的Microsoft SQL（由tSQL標籤假設）？ – Sparky

我期待大約20％的NULL值。我可能需要根據本專欄的內容進行一些搜索，但大部分時間範圍將被索引列減少到大約10萬行。每個條目大約200個字符。 – Benoittr

你也應該調查page compression，也許你可以做簡單的事情，並仍然得到一個小（ish）表。儘管如果你說的是SQL Express，你將無法像Enterprise Edition的要求那樣使用它。

我在我的項目中反覆使用了第二種方法。每個插入將不得不通過一個存儲過程來獲取查找值id，或者如果找不到並插入一個新的並返回該id。特別是對於像您這樣的大型列，似乎有很多行，但有很少的不同值，空間節省應該勝過查詢連接中外鍵和查找開銷的額外開銷。另見Disk is Cheap... That's not the point!。

來源

2011-12-08 22:16:16

儘管這個特定的數據庫正在運行一個快速版本，但我們在另一個上下文中部署了一個完整版本，並且頁面壓縮可能很有用。感謝指針。從所有的評論和這個答案我得到以下內容：除非你有一個特定的理由來反規範化，否則一直堅持正常的形式。 – Benoittr

我應該爲重複值（varchar）使用單獨的表嗎？

回答

相關問題