做制造業(yè)ERP的人,大多見過這種場景:產(chǎn)品分類字段里存著一串字符串——"家用電器>廚衛(wèi)電器>洗衣機"。查詢快得驚人,開發(fā)周期短得感人。但作者親歷的案例證明,這種"捷徑"會在系統(tǒng)膨脹后變成技術債務的深淵。
反規(guī)范化的誘惑很直接。規(guī)范化數(shù)據(jù)庫需要多表JOIN,產(chǎn)品信息分散在分類表、屬性表、關聯(lián)表里,查詢復雜且慢。把完整路徑塞進一個字段,讀操作瞬間提速,原型交付也快。作者提到,項目經(jīng)理和客戶往往急著看成果,"以后重構"的承諾就這樣埋下了。
![]()
代價在變更時爆發(fā)。某客戶系統(tǒng)里,分類改名或新增主類需要跑腳本更新數(shù)百萬條記錄。作者描述這個過程:"耗時數(shù)小時,錯誤率極高"。更隱蔽的是數(shù)據(jù)不一致——同一分類在不同產(chǎn)品記錄里可能拼寫各異,或路徑格式不統(tǒng)一,排查時如同大海撈針。
![]()
作者團隊曾開發(fā)產(chǎn)品樹管理模塊,用文本字段存儲"全路徑"。新增子類或遷移產(chǎn)品時,存儲過程要逐條重算路徑。這個設計在數(shù)據(jù)量小時運轉(zhuǎn)良好,規(guī)模上去后維護成本陡增。反規(guī)范化把查詢的復雜度轉(zhuǎn)移到了寫入和更新環(huán)節(jié),而ERP系統(tǒng)的分類調(diào)整恰恰是高頻需求。
![]()
技術選型沒有銀彈。反規(guī)范化在只讀場景或數(shù)據(jù)倉庫里仍是有效手段,但ERP這類寫操作密集、結構頻繁演進的系統(tǒng),需要更謹慎的權衡。作者的經(jīng)歷提示:那些被推遲的"以后重構",往往永遠不會到來。
特別聲明:以上內(nèi)容(如有圖片或視頻亦包括在內(nèi))為自媒體平臺“網(wǎng)易號”用戶上傳并發(fā)布,本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.