使用時間戳加整數作為主鍵
在 Sql Server 中，使用主鍵的缺點和缺點是：
兩個字元表標識符 + YEAR + MONTH + DAY + HOUR + MINUTE + MILLISECOND + 0 到 100 之間的隨機整數？
為什麼這比使用 Integer Auto_Incremented 欄位更受歡迎？（除非它不會，那麼我也想知道。）
我會喜歡為什麼這是一個非常糟糕的設計實踐的原因。為了取回該整數值而強制轉換所有內容也是一件令人頭疼的事情。
我基本上有機會讓我的開發人員小團隊訪問以幫助改進我們的應用程序的數據庫，這是它急需的——以避免出現主鍵 Varchar(50) 欄位左填充零的情況，或者只是開始改進非-規範化的數據庫，或一個欄位中的逗號分隔列表。
當然你可以做到，但你為什麼要這樣做？保存幾個 CAST 表達式？這似乎有點弱。
擁有自動遞增代理 int PK 的原因有很多：
- 您幾乎不必使用普通數據庫來管理它們。曾經。除非您要在必須關閉和打開標識的地方重建表或插入數據。但在操作上，它執行良好，成本很小。如果按照建議的方式進行操作，則會導致更多成本，因為需要 UDF 來創建密鑰，這比自動增量 int 需要更多的 CPU 週期來創建。
- 它們是最有效的儲存解決方案。您建議的方式需要一個 varchar(20)/char(20) 左右，這意味著每行 20 個字節僅用於密鑰。一個普通的 int 只有 4 個字節。它可能看起來不多，但在其中放入 1 億行，您會將大小增加約 1.5GB。不酷。然後你必須把它作為 FK 放在另一個表中，另外 1.5GB。或者在其他 3 個表中，您的數據庫不必要地大了近 5GB。你明白了……
- 表格應該真正與使用者不關心或不理解的東西聯繫在一起。這樣一來，您作為 DBA 就可以進行低粒度的控制，您可以參考這個值，使用者對此一無所知，這在進行高度粒度的更改、微調表或管理資料結構時變得很重要。我可以根據使用具有您建議的複合鍵的數據庫的經驗告訴您這一點。它們變得非常煩人，您總是很想只輸入一個自動遞增的 int 並完成複雜性和挫折。例如，想像一下，您希望快速插入一大堆來自不同來源的記錄。使用自動增量，對伺服器資源的影響最小。使用複合鍵…您必須執行為每個插入創建鍵的 UDF。.. 在您的範例中，每毫秒 100 個鍵的隨機化器可能還不夠，SQL Server 可能對您來說工作得太快，並為您提供 2 條記錄的相同 ID。該死的，您需要一種不違反唯一約束的不同方法。或者想像使用者出於某種原因希望開始“重用”一個密鑰（它會發生，有時是因為“回收使數據庫更快”的一些錯誤想法）。使用者最終試圖自己調整數據庫，這是災難的根源。在幕後告訴他們（並擁有）他們不理解的事情會產生一定程度的分離，這通常會避免這種情況。他們不會嘗試優化任何東西，將他們的小手指從您的業務中移開，這意味著您可以優化它應該完成的方式。
- SQL Server 需要 int PK-FK 自動增量並針對它進行了優化。由於插入記錄時的 FK 檢查，這將意味著整體處理速度更快。
整數之間的比較通常很快，對於 join也是如此。引擎中有很多針對整數/大整數的優化（太多無法列出），但作為範例，向下查找 b 樹可能使用線性插值而不是二分查找。作為第二個範例，當正規化表示適合 64 位時，批處理模式處理要快得多。integer 和 bigint 就是這種情況，但例如 UUID 就不是這種情況。第三個範例，可以將基於非空整數/大整數的點陣圖過濾器推入儲存引擎以進行早期評估。當不超過 64 位門檻值時，點陣圖過濾器在批處理模式下也可以更有效。 5. 最後，我發現自然鍵對於需要很少優化和管理的使用者很少的小型數據庫是絕對沒問題的。當查詢很簡單時，它們還可以進行更清晰的查詢（通過在 WHERE 語句中使用複合鍵），這意味著您連接的表等較少。但是一旦數據庫開始變得龐大和復雜……管理自動遞增整數代理鍵變得容易多了。
我最後的想法：複合鍵非常適合具有少量成員（意味著更短的複合鍵，因此空間要求低）的查找表，並且不會受到很多更改（意味著低管理成本）。一個例子是美國的兩個字母的州程式碼。它們將意味著可能會減少一個連接和多個儲存過程，這可能會帶來很小但可衡量的性能改進。
這絕對不是自動遞增整數欄位的首選。
對於初學者：
- 您的建議會顯著降低索引寬度。
- 您打算如何管理所有這些隨機的 2 位整數以強制執行唯一性。你有沒有想過要編寫和維護多少程式碼來實現這個方案。
- 不會為實現中的每個連接都輸入所有這些關鍵欄位是一種樂趣。
作為旁白; 你到底為什麼要在這個新欄位的每個實例中插入一個兩個字元的表標識符？從被檢查的表中可以立即看出該行形成的表。
如果您真的認為您在大量站點上的數據衝突率非常高，以至於證明這樣的方案是合理的，那麼至少使用 GUID，一種已經實施的技術，而不是這種 NIH 設計。
更新
自動增量鍵的單調特性在一些非常有效的計數表算法中用於執行總計（至少）以強制執行執行總計計算的正確排序。該方案將使這些算法的使用無效。