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