夢師作爲“後浪”，在某園區(唉 說我是廣告。。。)跟他一番討論讓我受益頗深，必須記錄下來。
從我學習軟件開發技術開始，基本都是技術思維。特別喜歡ER、3NF、OO，對於存儲冗餘的理解也往往停留在執行效率方面。長期以來都認爲，數據冗餘就是爲了解決查詢的效率的問題。而數據冗餘沒有處理好，還會帶來數據不一致的問題。所以，在設計時，能不用冗餘都不會去用。而在一個招標記錄複製編輯後再招標的功能測試時，我突然有所醒悟。
起因：
客戶複製以前的招標記錄，修改了標的物後就發出招標，系統自動發出短信通知投標方參與報價。投標方卻事後說沒有收到短信。我查了一下，發出去的短信並不是投標方的聯繫電話，只是投標方很早以前的一個電話。
追查：
招標記錄主要記錄了招標起止時間、標的物、投標方、投標過程、開標結果。其中標的物需要根據估價購買保險，投標方有名稱、聯繫電話。看到別人的設計，記錄下了標的物的id、名稱、估價，也記錄下了投標方的id、名稱、聯繫人、聯繫電話。我感覺這個冗餘存的真的是個大坑。按照以往，我可能就會存一個標的物估價的id和投標方id就可以了。這樣發送短信就不會取到投標方老的聯繫電話了。可轉念一想，這樣是解決了發送短信的問題，但招標記錄的意義就失去了。因爲當時投標人蔘與那次投標時的聯繫電話是多少沒有存儲下來（當然這裏先不考慮存儲結構的問題）就不能完整的記錄當時業務發生的現場情況，對於後續追查、追溯都不利。
思考：
設計上就建議產品修改爲複製招標記錄時，投標方聯繫電話不取招標記錄中存儲的冗餘，而取投標方最新的聯繫電話。就這個業務而言，投標方的電話可能發生變化，標的物價格也會發生變化。存儲的冗餘數據主要目的並不是爲了查詢性能，而是完整的記錄下業務發生時的現場情況。這樣的設計爲後續通過數據逆向還原業務發生現場，提供了數據支撐。此次跟夢師的溝通，讓我總結出了一個軟件設計的原則，數據存儲設計要考慮保護業務發生的現場情況，通過數據可以最大程度的還原業務發生現場。
============
感謝某園區(唉 說我是廣告)門崗、一體機設計師夢師。