請問各位大大,在做資料庫是不是一定會去做正規化,還是會考慮使用者問題在加上撰寫問題去考慮才決定是不是要做正規化(因為正規化會讓資料表變的多張,覺得程式上撰寫難度增加) 唯有學識與堅持才是成功的基石,所有事物被創造出來都是為解決問題

My 2 cents: Don't try to normalize because of you are told by the text books, normalize only when you think it is needed.

為了讓人們可以越來越懶 正規化可以讓人們減少輸入重複資料的機會

引言: 請問各位大大,在做資料庫是不是一定會去做正規化,還是會考慮使用者問題在加上撰寫問題去考慮才決定是不是要做正規化(因為正規化會讓資料表變的多張,覺得程式上撰寫難度增加) 唯有學識與堅持才是成功的基石,所有事物被創造出來都是為解決問題

就我個人的經驗來說 1.正規化的設計的確會降低許多重覆性資料的重覆建立, 可以達到資料維護的完整性及降低風險性, 當然如果你去看很許資料庫管理的書籍, 都建議你要以正規化來考量, 但正規化所帶來的一個很大的問題就在各關聯性之連結你必須能控制得宜, 否則一個環節出問題, 這個正規化馬上瓦解, 而且在sql上, 如果當你要做一個非常細微的分析時, 用到合併資料庫的動作增加, 勢必會增加程式設計上的困難度及系統資源增大的問題 2.如果不使用正規化的設計, 當然所有的情況就與上述是剛好相反的, 但有一點就是, 雖然會增加資料維護的困難度, 但這還是可以用程式來控制解決的 所以就我個人而言, 我會比較傾向於使用非正規化的做法, 但當然不可能把所有資料就用一個table來解決, 還是會將幾個重點結構給分出來, 例如單據的管理上就要分單頭及單身兩個table, 產品及倉別管理也是分成兩組建立等等, 因此如果你設計的重點在於分析資料呈現報表為居多的話, 建議用較非正規方式, 如果只是要建立資料為主, 那正規化應該是較好的考慮方式

個人的經驗, 談談資料正規化.    正規 / 反正規, 向來是資料設計的一項, 見仁見智, 難以取捨的問題.    個人覺得, 若您所要開發的系統, 須具備擴充性, 例如是 "產品化"的 ERP 系 統, 則須盡量將資料正規化, 因為這樣可以維持足夠的"彈性", 以適用於多種 客戶, 就算修調(客製化), 也可以較結省修改成本. 或許, 正規化會提高複雜 度與困難度, 但是, 其邏輯結構卻是清楚完整, 軟體工程師無須整天追著設計 工程師"問". 光從資料結構, 便可得知設計者大部分的思考邏輯與需求.    反之, 若您所要開發的系統, 不須具備擴充性, 需求相當明確固定, 例如是某 公司的管理系統, 便不須強調資料的正規化了.    舉個例子來說, 第一階正規 : 一個欄位不存入多個資訊. 以"姓名"欄位來說,  若考慮爾後有, 統計姓氏人數的需求, 是否須將"姓名"欄, 拆成"姓"欄與"名" 欄呢 ?    PS. 會思考資料正規化, 絕不會是新手, 更不可能是笨蛋喔.

個人觀點是視系統需求吧~以做一個員工資料建立作業來說 假設20人的員工的系統,那麼就可以把眷屬啦,部門職級啦...列成同一個table 假設2000人的員工使用的系統,那麼就盡量切出來