一筆業務要生成乙個序號，序號長度為20位，序號的規則是固定的字首(5位)+日期（yyyymmdd）（8位）+受理人序號（3位）+每日迴圈的序列號（4位）。例如
業務員001的業務編號
order201801010010001
order201801010010002
order201801010010003
order201801020010001
業務員002的業務編號
order201801010020001
order201801010020002
order201801010020003
order201801020020001
目前我想到的有兩種實現方式，如下
採用redis來實現，將迴圈序列號前面的作為key，比如order20180101001，order20180101002，設定乙個超時時間，目前是按天迴圈，則超時時間設定為24小時。value則是乙個自增的數字。這樣就可以滿足需求了。
採用關聯式資料庫來實現，列有seqprefix和nextval欄位，seqprefix是主鍵。獲取的時候檢視seqprefix是否存在，不存在則插入 seqprefix=「***」，nextval=2. 如果有，則取出當前的nextval，並+1更新。
以上兩個都可以滿足需求。方案1比較方便，不涉及資料表，方案2比較重一點。不知道業界還有沒有其他的方法來實現。
關於業務主鍵和邏輯主鍵
關於這個問題網上已經有很多的討論，現在綜合這些討論在加上自己眾多建模及資料倉儲工作中的經驗給出以下分析及取捨建議，供各位同行參考 一 業務的東西，是每乙個做軟體的最薄弱的，並且是最有可能受到客戶影響的，也是最會引起問題的。比如身份證，如果有系統的錶用此做主鍵，其他眾多表以此為外來鍵，當身份證從15位...
主鍵設計原則
1.是否要採用guid作為主鍵 用guid作主鍵有它的優勢與不足.優勢是guid具有唯一性,在任何情況下,可以產生全球唯一的值.這是guid最大的優勢,也方便資料匯入,比如要求從另乙個系統中把資料匯入進來,那麼,不用擔心,匯入時,會導致主鍵衝突.不足是guid值太複雜.不易記憶,因為有時,難免我們會...
MySQL 主鍵設計原則
主鍵和外來鍵是把多個表組織為乙個有效的關聯式資料庫的粘合劑。主鍵和外來鍵的設計對物理資料庫的效能和可用性都有著決定性的影響。必須將資料庫模式從理論上的邏輯設計轉換為實際的物理設計。而主鍵和外來鍵的結構是這個設計過程的癥結所在。一旦將所設計的資料庫用於了生產環境，就很難對這些鍵進行修改，所以在開發階段...