2014-11-04 47 views
1

比方說,我有一個客戶表:第一個和最後一個名稱表可提高性能?

CustomerID | FirstName | LastName 
1   | John  | Smith  
2   | John  | Adams 
3   | Kevin  | Smith 
4   | Kevin  | Adams 

現在想象一下這個表有20萬個+行。它會提高性能來創建一個單獨的FirstName和LastName表,如下所示,然後使用連接來獲取上面的視圖?

例子:

FirstNameID | FirstName 
1   | John 
2   | Kevin 

LastNameID | LastName 
1   | Adam 
2   | Smith 

CustomerID | FirstNameID | LastNameID 
1   | 1   | 2 
2   | 1   | 1 
3   | 2   | 2 
4   | 2   | 1 
+1

因此,不是在一張表中查詢一行,而是在客戶表中查詢一行,然後再添加兩個查詢並加入結果?你猜猜哪個更快。 – JJJ 2014-11-04 17:37:13

+0

我不這麼認爲...... – 2014-11-04 17:37:48

+2

這與標準化有*無關。 – 2014-11-04 17:40:25

回答

2

這取決於您的查詢工作量。這是一種簡單的數據壓縮形式。減少回答給定查詢所需的一組數據可以提高性能。

另一方面,你在許多地方引入開銷。這是一個權衡。如果你想檢索這些列的值,你現在需要加入。 DML也變慢了。

由於名稱列可能相當小,因此很難想象會受益於此方案的查詢工作負載。

DATA_COMPRESSION和備份壓縮可以替代。他們做出了非常不同的折衷。

只是爲了證明你的方案有價值:想象一下很長的名字和一個巨大的(TB大小)表。節省的空間將會非常重要,因爲名稱並不多。

+0

不,壓縮不起作用,因爲聚集鍵可能在CustomerId上 - 這意味着您可以獲得有效的隨機名稱。會有所作爲,但不是那麼高。當您設法擁有正確的聚簇索引時,壓縮功能非常棒。 – TomTom 2014-11-04 17:54:16

+0

取決於頁面上有多少個名字。也許很多「史密斯」的。好點子。 – usr 2014-11-04 17:58:45

+0

其實沒有。問題是,除非你居住在中國(其中大部分有5個姓我被告知),你有很多。可悲的是,人們不會被「史密斯」命令,但最有可能是一個ID(1,2,3)....這意味着名稱的順序是隨機的。然後在一頁上沒有多少史密斯。 – TomTom 2014-11-04 18:00:31

0

沒有涉及該會作出具有聯接三個表更快名稱的任何行動。

簡短的回答:第

+0

使用ID號替換文本與規範化無關。 – 2014-11-04 17:42:20

+0

我已經刪除了對標準化的引用。當我瞭解到正常化時,我很確定我得到了一個這樣的例子。它必須去除所有冗餘數據。我被教導說,這是「超越」第三範式的,超越實際的 - 一種沒有益處的學術活動。但那是很久以前的事了,我可能記錯了。 – 2014-11-04 17:49:44

+1

它肯定與標準化有關,但我同意這可能不值得。 – 2014-11-04 17:51:45

4

是否有這樣的舉動會提高性能取決於什麼查詢執行的,但它很可能做相反的許多我想象你想要執行的查詢。

+0

我很好奇哪些查詢可以更快? – 2014-11-04 17:54:55

+1

智能開發人員在主要可視化的服務器上編寫的任何內容。只要不過濾,就不需要在任何查詢中讀取名稱和姓氏表,因爲您可以從緩存中獲取名稱。在那裏,做到了,速度提高了10倍以上 - 但我們的用例非常特殊。 – TomTom 2014-11-04 17:56:13

+2

我很驚訝這是被接受的答案,因爲它所說的是「也許它有效,也許不是」。 – usr 2014-11-04 18:02:08

相關問題