若使用 IDENTITY 等資料庫自動產生的方式給予識別碼
當資料列被刪除時，序號就會產生截斷
所以主索引鍵序號的值應從應用程式產生
例：
1 訂單#1
2 訂單#2
3 訂單#3
若今天刪除「訂單#3」然後再新增一筆訂單就會變成
1 訂單#1
2 訂單#2
4 訂單#4
應該是
1 訂單#1
2 訂單#2
3 訂單#4
這是一個很有趣的論點
上述情境中編號 3 的訂單不見是件「非常合理」的事情
大部分取得訂單會使用流水識別碼
若今天 3 被刪掉然後又新增一筆 3 出來
使用者就會發現：
今天我編號 3 的訂單怎麼跟之前不一樣了（因為顯示為訂單#4）
若使用應用程式來管理序號
就需要注意在水平擴充調整規模時會不會產生衝突
所以遞增序號應該由 SQL Server 負責提供
無論是使用「序列 (Sequence)」或是 IDENTITY 皆可
可以更加確保資料的一致性
以這標題與內容 "個人" 我會寫 "不要隨便刪除任何資料"
所有的資料可以後續可做為 "分析使用者的行為" 一經刪除後續的系統的改進與尋找設計上的缺失就會無法有機會改進...
以作者的所使用的技術，我會單純認定為 "程式設計師兼資料庫設計" ，所有對於資料的認定以 "程式人員方法" 。 但資料表設計的好壞與規劃可以 "反解" 程式邏輯是如何..
這題：「問與答：資料表流水識別碼不應使用自動產生」 的理論不太認同，正式環境就算是任何無效訂單，最好在欄位中註記 "不展示或是不顯示" 此筆資料即可。
過久的資料可以在 "設計階段" 就要有 "歷史資料庫" 設計模式，任何資料後續都可以再次的分析 使用者 「行為與目的」來改進相關 系統 各種穩定性以做為下次改版或是設計方向。
[所以主索引鍵序號的值應從應用程式產生] 不應該由程式產生 而是將資料丟給 SQL 寫一段 SP 以「資料表的規劃」來寫入並且以「規劃」來決定資料是如何處理!! 程式人員專心搞定前後端要做與設計的畫面，就算要兼任設計資料庫 「思考模式請以 DBA 的思考模式與設計來決定應該要如何做」
iThome鐵人賽
看影片追技術