資料庫記錄的歷史版本怎麼設計比較好？

如同知乎的問題一樣，每次修改的歷史記錄都會保存下來。通過加一個version欄位，這個應該很容易實現。但是對於我來說就有這樣一個問題了：我的程序是用記錄的ID來關聯一些具體信息的，如果修改了數據則建立新的記錄，其對應的ID就會發生變化，那以前已經建立好的關聯關係就會被破壞掉。當然，也有解決辦法：
1. 如果其他地方檢測到ID已經無效，則通過某種方法跳到有效的新紀錄的ID。這樣做似乎對效率有所影響。 2. 把原始記錄複製一份到一個新建記錄當中，然後直接在原始記錄裡面進行更新，保持有效ID不變。

這兩種方法我都感覺不是太好。大家有什麼更好的方法？

「如果修改了數據則建立新的記錄」最好不要這樣，因為你這個記錄和其他的表關係應該是穩固的單獨建立一個version表保存修改記錄和問題表的關係：n:1

如果你瞭解java的話,使用hibernate的envers就好了，原理就是會對每一個需要記錄歷史的表建立一個對應的歷史表，每次更新就拷貝出來一份，生成一個新的version,和svn類似的。磁碟便宜，不用太省，該買就買。

時序資料庫 =_=

聽說過ID生成器沒有？主鍵不自增，而是通過一個ID生成器來確定，

1.這樣好處很多，ID可以做到全局唯一，不可變，類型可選（一般long,或者char），強關聯，利於分散式擴展，好處多多，2.壞處較少，存儲空間較大（要做到全局唯一所以比較長），需要額外的程序處理（大部分走網路，小應用可以走單機），需要開發人員熟知，避免混亂。

你覺得怎麼樣呢？

我覺得一張表好一些。在表中除了設置自增長的id，標識數據是否刪除的status兩個欄位之外，再加一個數據唯一的code欄位。修改數據時把status更新為已刪除狀態，添加一條新記錄設置同樣的code即可。這樣的方法在有離線客戶端添加數據時也非常有用。如果數據量越來越大，可考慮定時清除或轉移歷史記錄，刪除的時候做回收站功能也相當便捷。如果主庫壓力非常大，就建一個從庫專門存放歷史記錄，也沒辦法了。