我覺得很重要(推眼鏡)
就像泰大D槽,重複的影片要砍掉,不是清晰的砍掉
才能實現D槽最佳化

我心想：每種技術、理論的發展，都有其時空的因素。

不曉得是不是翻譯的關係，
Normalization 被翻成 正規化，
聽起來就很偉大，
不大曉得這翻譯的來由，
但猜想可能是從日本所翻譯成的是這 三個漢字，
直接引用過來。
(但我也不曉得到底是中文先有此譯還是日文先有)
如果你不正規的話，難道你要旁門左道化嗎？
你不當正規軍，你要當雜牌軍嗎？
正規的的涵義就給乖乖牌成為不二的選擇方向。
但隨著網路社群發展的趨勢，
及軟硬體的規模已不像以前的受限制情況，
RDBMS 不見得是唯一或最有效率的方案，
也許依不同的議題，
NoSQL 做為輔助或主要的 DB，
可能比一堆 table join 來 join 去更有效率，
只是NoSQL還沒有像RDBMS已登入正規教育裡的內容，
不曉得有多少教科書或學校的課程，
是否已有或者何時會出現在其中？

這篇 A Managers Guide to NoSQL，
算是給管理者或一般人簡介NoSQL裡的重要概念入門，
跨出30年前的經典或舊概念。

除了省空間外, 主要還有一個功能是"避免重複的修改資料"

比如一個客戶公司的名稱, 也許在很多地方會查詢, 但幾乎不會異動, 所以透過正規化減少重複修改的情況. 但如果真的有異動公司名稱的需求, 就要再考慮反正規化或設計表格上的增加異動記錄, 確保過去的資料查詢結果正確.

其實以現在的 DBMS 設計, 往往資料不大, 反而 log 跟 index 設計不好的話, log 跟 index 比較大.... XD

維基的說明中指出
正規化的目標有四點

而在DeNormalization的說明中，也有提到 OLAP 的情形比較適合用 DeNormalization

我想
1.加快執行速度
2.減少使用儲存空間
或許才是持續追求的目標吧

師長說：正規軍要資料庫化... 老實說：這...到底對不對？？？

正規化
這個在關連資料表的應用上
用PK與FK串起多個相關的資料表
優點是減少重複的資料, 以及保持欄位值的一致性
但是查詢時應該會變慢一些

所以
反正規化還是得看情況使用
當Select不使用一堆 join 去串起關連的資料表時
通常會比較快

正規化最大的好處在於......你撈到得資料不會出錯…
沒有正規化，你敢保正說…你取得的資料內容一定是最新的?
(我就看過…因為沒有『更新』只會累積的...excel表(它自動跟資料庫要的資料，有old就沒更新…)

軟體工程(Software Engineering)是十分嚴謹的, 正規化是一種工程安全規範, 如果不做至少三級的正規化, 等於是偷工減料, 這種偷工減料的做法, 在軟體的表層, 如界面與大部分的操作, 是不容易能被查覺出來的, 只是不知問題會何時爆發, 對於軟體使用者來說, 即使對軟體不是專業, 還是可能覺得怪怪的, 因此會有信任疑慮. 對於軟體發展者來說, 軟體的品質會不穩定, 軟體的維護成本可能會不斷增加.

不是說每個人都會堅持正規化, 因為衡量短期的成本, 忽略軟體工程安全的人也不少, 追逐短期的獲利也是人之常情, 但是, 軟體也是一項藝術, 再些微的裂痕, 都會減損藝術品的價值.

至於重複性與相依性, 這是技術問題, 可能使用更高階的電腦設備可以掩飾掉偷工減料的部份, 但是僥倖的做法, 是不會長久獲利的.

Normalization
想到"常規化" 或 "常態化" ....

硬碟再大, 也拼不過資料的增長速度. 正規化還是有其必要性.

正規化還是有其必要性(以SQL資料庫而言)，
但還是是搭配小技巧。

如經常查詢且用到join，就可以將Join資料寫到主表的欄位，
只有新增刪的過程去更新對應資料，
定期更新整個資料表，
以確保關聯一致性，
資料正確及效能都能顧及。

我能想到的理由是，就跟寫程式一樣，重複的資料越少越好
最好是可以做到沒有重複。
沒有正規化，就可能會有重複的資料

如果有重複的資料，事情就會變得比較麻煩
因為，當你更新資料時，必須將所有有儲存的地方一起更新，如果漏掉一個
也可能不會馬上出問題，因為他就像地雷一樣，不知道什麼時候會被踩到
一但踩到了，他就爆了~

...嘿咩...偶而也要上來開個幾槍...
人家黃興一次開三槍...我才開了一槍，就有這麼多大師響應