分析:
發送方不同數據庫是自行管理公司代碼, 所以代碼在同一數據庫內是唯一, 但在全部數據庫裡未必是唯一。更大的問題是同一個客戶在不同的數據庫可能有不同公司代碼。
解法:
- 在公司代碼前面加上數據庫代號。
好處: 簡單
壞處: 如果同一個客戶出現在多個數據庫, 這個客戶會有多個不同的代碼, 所以代碼並不是唯一。 - 為每一個客戶編定唯一識別碼。
好處: 可確定識別碼是唯一的。
壞處: 可能會花很多時間去確保識別碼是唯一的。
教訓:
提早定義全域唯一識別規範
在多資料來源系統對接前，應先決定唯一識別碼的生成與維護策略。若一開始依賴本地（資料庫內部）代碼作為主鍵，後續整合時幾乎必然出現衝突與對應問題。
避免將內部業務代碼當作跨系統識別碼
公司代碼、客戶代碼等通常是業務邏輯層概念，而非技術上保證唯一的 ID。它們可以保留作輔助欄位，但不應作為整合集成的關鍵識別依據。
建立唯一識別碼需要統一管理機制
若選擇集中式唯一 ID（例如 UUID、全域客戶 ID），需設立負責生成與維護唯一性的權威系統，避免人工重複核對的高成本。
在整合設計中考慮真實業務意義對應
即使技術上有唯一 ID，也要確認能正確反映「同一客戶」的業務實體。必要時應建立「客戶主檔」（Master Data Management, MDM）來處理跨系統實體的關聯與比對。
短期方案應可平滑遷移至長期方案
若初期時間有限，可採用臨時方案（如加資料庫代號前綴），但需為未來導入統一 ID 預留遷移機制，避免資料重構困難。
聲明：本作品包含在人工智慧協助下產生的內容。作者已對所有材料進行驗證與編輯，以確保其準確性與完整性。
發佈留言