正規化(Normalization)這名詞有學過資料庫的人應該都聽過…
我剛剛學資料庫的時侯真的搞不清楚這三個字的含意…
也完全不知道為什麼要正規化…
到後來…我才知道…原來丫…
正規化就如同書本上所說的:
A.欄位唯一性 (Field Uniqueness)
B.主關鍵欄位 (Primary Key)
C.功能關聯性 (Function Dependence)
D.欄位獨立性 (Field Independence)
管他的什麼1NF->2NF…反正他的意思就是…
當成鍵值的欄位不可以重複,
資料重複出現的欄位分解到另一個table,
欄位的關聯要明確!!!
事實上,如果每個資料庫都依正規化這樣去拆…
帶來的好處是資料乾淨、關聯明確、
不容易出現多餘重複的欄位…節省實體記憶體空間!!!!
在系統的開發階段,過度的正規化不見得是一件好事!!!
有一陣子,我像是著了正規化的魔…
後來發現,提升效能的最大殺手就是過度的正規化!!!
為了查詢顯示出資料,做了七、八個table來關聯資料出來…
如果可以把這些關聯給簡化…效率不是有很大的提升嗎?
當資料超過十萬筆、二十萬筆時…花費在關聯的時間應該是當時倍數吧??
搞不好是0.001秒(沒關聯)與 0.1秒(有關聯)的差別------>100倍哦
(聽說超過六個關聯…資料一多時效能就會被拉下來)
小弟最近系統開發過程中在調校的階段
試著把一些常用的關聯給反正規化
也就是說,讓他回來原來的表格…
讓原來需要關聯四五個talbe的查詢簡化至一到二個table關聯!!
或許因此多了幾個欄位(浪費了硬碟空間-->現在的硬碟空間應該不用怕不夠用吧!!!)
但是反正規化的操作當資料大量查詢或交易時,
在效能上將會比先前有明顯的提升!!!
對於某些人說來(就是我)這曾經是個迷失…
事實上…做反正規化時-->心態上不可以有潔癖!!!!
我剛剛學資料庫的時侯真的搞不清楚這三個字的含意…
也完全不知道為什麼要正規化…
到後來…我才知道…原來丫…
正規化就如同書本上所說的:
A.欄位唯一性 (Field Uniqueness)
B.主關鍵欄位 (Primary Key)
C.功能關聯性 (Function Dependence)
D.欄位獨立性 (Field Independence)
管他的什麼1NF->2NF…反正他的意思就是…
當成鍵值的欄位不可以重複,
資料重複出現的欄位分解到另一個table,
欄位的關聯要明確!!!
事實上,如果每個資料庫都依正規化這樣去拆…
帶來的好處是資料乾淨、關聯明確、
不容易出現多餘重複的欄位…節省實體記憶體空間!!!!
在系統的開發階段,過度的正規化不見得是一件好事!!!
有一陣子,我像是著了正規化的魔…
後來發現,提升效能的最大殺手就是過度的正規化!!!
為了查詢顯示出資料,做了七、八個table來關聯資料出來…
如果可以把這些關聯給簡化…效率不是有很大的提升嗎?
當資料超過十萬筆、二十萬筆時…花費在關聯的時間應該是當時倍數吧??
搞不好是0.001秒(沒關聯)與 0.1秒(有關聯)的差別------>100倍哦
(聽說超過六個關聯…資料一多時效能就會被拉下來)
小弟最近系統開發過程中在調校的階段
試著把一些常用的關聯給反正規化
也就是說,讓他回來原來的表格…
讓原來需要關聯四五個talbe的查詢簡化至一到二個table關聯!!
或許因此多了幾個欄位(浪費了硬碟空間-->現在的硬碟空間應該不用怕不夠用吧!!!)
但是反正規化的操作當資料大量查詢或交易時,
在效能上將會比先前有明顯的提升!!!
對於某些人說來(就是我)這曾經是個迷失…
事實上…做反正規化時-->心態上不可以有潔癖!!!!
文章標籤
全站熱搜

很支持您的想法。 在我們公司就有人老喜歡用所謂的正規化。 把一堆有的沒的質都數字化。 比方說 TW=1 CN=2 HK=3 US=4 等等等.. 我們所要的只是單純的把資料給 select 出來 "看" 照他所設計的表基本上直接 select 出來都是不能 "看" 的 一定要case 或是 join 這些數字成人看的懂的字才比較能 "看" 我們的資料庫主要都是存一些 log, 在必要時可以 select 出來看。 在 select 時還要 join 來 join 去的... 真不知道為什麼他喜歡把事情想的這麼負雜。
樓上朋友,謝謝您
你好, 雖然是蠻久之前的文章, 但還是想回應一下....XD 在系統初上線時, 因為資料量少, 所以資料join等等的問題, 還不至於把效能拖下來, 當主要table累績到一定資料量時, 效能就很明顯的給拖了下來。 此時別說是join七、八個table, 連join一個table都可能會覺得超慢。 此時就會依系統再重構一次功能, 先歸納出那些資料只用來查詢, 那些資料還有可能修改。 用來查詢的資料給它徹底的反正規化, 完全不使用到join, 再移到另外查詢的table, 將原有的資料刪除。 而這查詢的table就只提供查詢使用, 簡單的來說就是分使用區、查詢區。 以拍賣網站的例子來說, 已經結標的資料就移到查詢區, 未結標有可能修改的資料就不動(使用區)。 我這裡的經驗是, 反正規化後的資料, 有用到index的情況下, 二、三百萬筆資料花不到一秒的時間就可查詢完畢, 使用區的資料最好只累績到10萬~20萬, 不過這是理想值... 不過, 雖然系統效能增加了, 卻也增加不少系統維護的複雜度.... 另外, 若要增加DB效能, 也可以研究看看partition table。