今天跟同事討論金流處理的設計，在資料庫方面有認知上的不同。
1.我偏向DB自動產生流水號當唯一鍵和做索引，訂單編號另外產生，同事想用程式產日期加流水號當唯一鍵，順便當訂單編號
2.我想將子公司這個分類拆成另一張表來關聯，所以有兩張表，同事認為我過度正規化，認為在編號上用A、B表示即可。
在想我是否太堅持使用正規化，所以去查查網路上對於反正規化的看法，其實連我主管也認為正規化是學校再教的。
對於一般生命週期短的活動專案，個人是同意不用正規化，因為效率優先，而且也不用多花工。
但在設計金流處理方面，總覺得要有個正規化，因為以後的活動都會使用到這功能，所以我是以系統的角度來思考。
因為我跟同事還有主管都不是DBA的專長，所以想請教各位在這種專案上會傾向怎麼處理。
如果訂單編號會重覆，或是訂單編號是可以變更的，你的做法就是正確的...
一般一階正規化要做比較好...
第2點，其實多個欄位紀錄就好，不需要另用資料表，但也不要像你同事說的那樣...
我怎麼覺得你同事的說法才是正規化的方式，如果你的訂單編號是唯一不會重覆，那就當KEY阿，為何還要弄個流水號？
想法是mysql 自動產流水號與索引，一直覺得這樣比用訂單編號來做 join與查詢上有效率，想說流水號是給電腦使用，訂單編號是給人來辨識使用，不知是我認識有誤。
如果訂單編號會重覆，或是訂單編號是可以變更的，你的做法就是正確的...一般一階正規化要做比較好...
訂單號碼不會重複，只是不了解這對資料正確與JOIN、索引是否會影響到效能，雖然分表處理不好也是降低效能...
第2點，其實多個欄位紀錄就好，不需要另用資料表，但也不要像你同事說的那樣...
多個欄位，就會覺得那可以記錄成數字1,2,3，那這樣就可以順便一張表，看要不要順便join秀出1,2,3是哪幾間公司
redial wrote:
千萬不要這樣做, 除...(恕刪)
同意
除非該系統打算用上二三十年
而且可能會有上億筆資料
真要效能好 還是直接提升硬體比較實在
用自動編號的流水號來當key 還要多一張表來紀錄跟串連
只是把程式設計師撈資料的動作弄得很複雜
而且 如果記錄的表出現問題 那資料要修復我想應該頗有難度
另外一題
本來我有客戶買E3的伺服器主機 硬碟是用原廠配的500G硬碟做RAID1
跑MSSQL 記憶體是8G 配給資料庫的記憶體配6G
客戶反應跑資料下整年度非常慢 (筆數大概十五萬筆左右)
第一點是AP沒寫好 沒有預先把所需要的資料表日期區間範圍先LOAD下來在本機再串報表
而是打上一大串的SELECT語法去串十幾張資料表然後計算加總等等的...
一下指令整台伺服器 CPU馬上飆到100% 直接影響到其他使用者
因為AP沒辦法要求廠商修改
於是最後將RAM升級到16G 500G硬碟換成240G SSD
本來跑一年資料要影響所有使用者大概45分鐘
換SSD之後 縮減剩下10分鐘就跑完了
SSD萬歲~
jo87fish wrote:
今天跟同事討論金流...(恕刪)
貓老闆
內文搜尋
從 APP 打開
X