隨筆
SnowFlake的使用體驗：
本次吸取上個項目經驗，整個項目的數據庫id都採用了 snowFlake，先說一下體驗吧，snowFlake的確還是好用的，特別是在一些數據庫操作上很方便，不用考慮很多，直接copy就完事了，出了問題修復上也比較方便：體現在如果缺少數據，你從主鍵上直接搜索就能很快定位缺失的數據，當然這種情況基本都沒有出現。如果使用的是自增主鍵，要定位缺失或者不一致的數據，自增id並不能作爲你參考的條件，你只能通過業務數據進行篩選定位。
從業務主鍵過渡到id主鍵：
上個項目我們的主鍵採用的是業務字段聯合主鍵，這是因爲之前的老項目全是oracle而且都是聯合業務主鍵，這樣做的好處也明顯，數據的完整性不用後端去考慮，凡是不符合基本主外鍵關係的數據，不會寫入到庫裏造成數據的污染。但是隨着我們之後的項目逐漸過渡到以mysql數據庫爲主，業務主鍵的查詢效率會下降，而且msyql也不推薦使用主外鍵關聯，即數據完整性的控制，大部分都放到了後端程序。
本次項目的教訓
這次項目的教訓呢，是我一時沒想明白，竟然用一個服務中某個實體的主鍵作爲另一個服務的表的主鍵值進行保存，因爲都是用snowFlake規範，不會出現主鍵衝突問題，而且這兩個實體是強相關：都是某種用戶的身份信息數據，只不過因爲業務需要，才強行將註冊、審覈、激活進行了系統上的拆分，嘛，我當時認爲不會出現問題。
然而，你永遠猜不透業務會提出什麼需求，這種操作是要付出代價滴。現在業務突然提出了一個需求，導致我自認爲強相關的實體，在A、B兩個服務出現了不對應的情況，我爲了在A中保存新數據，不得不將某些老數據做成軌跡表進行記錄，否則會有主鍵衝突的情況。
在這裏記錄一下，強相關就是不等於，兩個系統你認爲是一類甚至是相同的數據，會因爲不同系統的拆分，不同系統的不同操作，導致最終不一致。
正確的做法應該是，記錄本系統自己的id，並記錄另一個系統相關數據的id作爲一個字段，這樣對於需求的變化及兼容性就能提升很多了。