個人積分：1758分
文章編號：55058476
那邊的人看法不太一樣，我貼過來大家研究研究，只是有點一長串，
在想是不是(程式開發者) 與 (設備架構者) 看的角度不同，所以導致分成兩派看法!?
以下是別的網友討論內容
-------------------------------------------
Norma---- 以正規化來說，正規化跟反正規化並不是互斥的，通常在一開始設計規劃時會以正規化為主，到實作階段時，再根據現實狀況逐步反正規化
回到你的問題，問題 1 你們兩位想法差異不大，只差在處理 duplicate key 的問題，不過問題不大；問題2，要看子公司分類是否為 1 對多關係，如果是的話就先拆，如果是 1 對 1 的話都可，以上淺見
-------------------------------------------
Jin Hu---- 第一點我會跟你一樣, 但第二點要看層級到底有幾層~ 如果只有兩層我只會用一張表來做~
反正規化的table我常常都是site online之後拿來處理效率問題用的~~xd 所以覺得這兩者沒有甚麼太多的問題~~
-------------------------------------------
Chi ---- 1.訂單編號另外產生比較適合
2.不同來源訂單應該可以多開一個欄位記錄AB就可以
除非要紀錄的資料有很大的差異性
-------------------------------------------
Moby---- 訂單編號想必是唯一，也就是說照你的方法，一個table有兩個唯一的欄位，有這必要嗎？
-------------------------------------------
Norman---- 有必要啊，你可以想像寄給使用者的 email 上面寫著
"您的訂單編號 #1" 嗎
-------------------------------------------
Moby---- 既然訂單編號是唯一，為什麼執著於要有流水號？
-------------------------------------------
張---- 1.用流水號當作訂單編號就好，不應該把日期放進去，日期另外放一個欄位 (不然以後有人就會只看訂單編號的某些欄位來判斷日期)
2.子公司跟原 Table 的資料，在使用上有什麼差異？跟其他資料的關聯性有什麼差異？如果都沒有差異，頂多加個欄位註記即可
-------------------------------------------
Chi---- 很多業主希望訂單編號可規則化 但拿來當流水號 變成要跳號
感覺不是很環保
-------------------------------------------
Norman---- 其實用不用流水號我是覺得都可以啦，能好好處理 duplicate key 就好，我以前是只用固定規則去產生 key，有流水號是比較沒有這個困擾
-------------------------------------------
Jin---- 我開table的習慣都是先開流水號xd 其他欄位慢慢想~~ 流水號拿來放後台用很好用啊xd
-------------------------------------------
Clive---- 請教各位大大：流水號太大(編號太長)會不會佔用太多資源????
-------------------------------------------
Chi---- 基本上不要超過20個字元
大部分金流公司只接受20字內的訂單號
-------------------------------------------
檀---- 記得拿來給Primary key作為篩選辨識用的欄位，字越少越好，所以我習慣用流水號，極其簡短
-------------------------------------------
檀---- Clive---- 若primarykey是流水號應該是最省資源的。我是另開訂單欄位，使用時間值。系統比對則用流水號
-------------------------------------------
Lai---- 如果是很大的系統，是要用正規化去做基礎建設，隨著開發遇到的效能問題，我才會用反正規化的概念去處理。
畢竟之後維護還是要靠自己，資料有問題倒楣的是自己。不是主管，光一個資料在資料庫存放著很多地方多有，一定會累到自己。
-------------------------------------------
An---- 謝謝各位解說，認知上也是習慣先有流水號，之後編號在開欄位，但後來也看到不少教學範例是訂單編號直接當PK用，並沒有流水號，所以有點混亂。
-------------------------------------------
張---- 我的話會用 PK = 訂單編號 = 流水號，或是 PK = 訂單編號 = UUID，總之一定要 Unique....
-------------------------------------------
張---- 一.訂單編號, 目的是要識別用, 只要是key就好, 何必管它怎麼產生 ? 但如果訂單是Master/Detail , 則Detail除了Master的key之外, 還要有另一個欄位來組合成key
二.子/母公司需不需要拆表 , 要視情況而論 , 你的描述過於籠統
三.絕對是要正規化 , 可以用實測資料在Excel中模擬比對看看, 這樣比較準 ; 但過度正規化, 確實也會徒增程式數量, 造成尾大不掉的困擾
-------------------------------------------
Jin---- 如果拿訂單編號而不是流水號當唯一key, 在order_detail table的時候不就要用那個一大串的string去join ??
-------------------------------------------
吳---- 一般來說開訂單的時候系統不一定剛好在手邊，剛好能上線。
系統故障或定時維修時你也不能/不該和客戶說要等系統修好我才可以處理訂單。
這類的工作都要保留一個手開流程在系統離線時可用。......查看更多
-------------------------------------------
周---- 想問各位大大，對於安全來說，訂單編號加上幾位亂碼會不會比較好？
每次看博客來的編號都長到不想看，可是很明顯就是日期加上什麼東西的
-------------------------------------------
建---- 1.order_id 跟 order_sn同時並存即可,許多訂單系統都是兩者並存的
2.原則上建議拆表,這不單是正不正規的問題,在海量資料時不拆是會成為性能負擔的,當然,如果可以預期就是個數十萬筆的規模,就不會有太大差距
-------------------------------------------
( 這篇最長，要看完真的表示非常熱血阿! )
Y----
因為內容有點長, 所以另外發一篇來討論An----提出的議題
我覺得要以比較科學值觀的方式來看待你提到的第二個問題
以我個人的經驗來說, 資料庫設計會以儲存,取用,維護三個面向去思考 三者兼備才是比較可行的設計, 不然到時候還是要花時間去補救, 並沒有比較省事
一般來說, 資料庫正規劃設計才會好存取維護, 那為什麼會有反正規劃呢? 不是為了開發速度, 多半是為了存取效能, 就是所謂的用空間換取時間, 但因易維護性降低要另外花功夫去確保資料一致性, 故要做反正規化前, 要先視需求面來決定, "如果沒有判斷依據, 那建議就不要做這件事情"
[情境思考]
1. 假設訂單中表某個子公司的Data row有100萬，這時候以反正規化的作法，假設我子公司名稱要修改，就要一次更新100萬筆資料，這是非常吃資源的，整個資料庫可能都會卡住
2. 當你更新子公司個人資料時, 同時有該子公司的訂單寫入, 可是sql取出卻是舊的資料, 兩個操作同時發生的狀況下, 這時候資料就產生一致性的問題
3. 當子公司資料有n個欄位時, 反正規化設計下, 代表你訂單表要多出n個欄位, 整個變得更肥大, 當你要新增or刪除某個子公司欄位時, 整個訂單表一樣會卡住做Schema更新與Index建立
4. 當訂單table有分表, 備份, 或是Partition的切分下, 反正規化作法資料維護工作會是悲劇, 更不用說performance
綜觀以上問題，您提到你同事提到的點，比較沒有辦法說明為什麼要反正規化，個人建議是"如果沒有理論依據判斷需求存在, 那就不要做反正規化這件事情"
以你的案例來推論, 可能的應用情境我想因該會有讀取某條件下的訂單, 並帶出子公司名稱資料組成一個報表, 這時候普通的寫法就是用join來存取兩個table, 一句sql搞定, 可是我們思考一下訂單表大, 子公司表小, JOIN的performance會比Simple select來得慢, 特別是當table大時, 感覺會很明顯, 有興趣可以實驗看看
這個時候我們會以兩次simple select 的方式來做, 先存取訂單表, 再把這批訂單資料列內的所有不重複子公司ID, 組成另一句SQL, 拉出子公司資料, 共兩句SQL分兩段來執行, 效能表現會好很多, 並且系統會更可靠
訂單表大, 子公司表小, 而且子公司資料因該很少變動, 這時候可以思考加上cache機制, 應該可以再提升performance
以上一些見解，如有不對之處再請指教
