如何構造數據……是順序的還是分層的？

Question

我正在構建一個CMS，每次收到新的銷售訂單時，該CMS將組織我的雇主生成的許多常見文檔。 每個新的銷售訂單都有一個5位數字（12222、12223、122224等），但是在內部，我們對這些數字應用了層次結構：

+ 121XX
|--01
|--02
+ 122XX
|--22
|--23
|--24

在我的銷售訂單表中，最好使用5個數字作為ID並填充，還是使用我們在常規對話中引用工作時使用的層次結構更好？ 在我看來，不按順序填充的唯一好處似乎是稍后格式化數據，但這聽起來不足以作為進行額外工作的充分理由。

謝謝

Answer 1

最肯定的是，您應該使用5位ID作為主鍵。 有時，顯而易見的答案是簡單的答案。

Answer 2

“為在數字標識符中賦予子字段含義的人們保留了一個特殊的地獄。”

盡管我可以肯定並贊賞此話，但我不得不補充一下，如果業務如此，這恰好是用於訂單的編號系統，並且碰巧業務確實附加了含義，子領域，那么實施支持該業務的自動化系統的IT人員別無選擇，只能依靠該編號系統。

（那些IT人員可能會指出此類系統的缺點，但它與IT人員無關，它決定了業務內容應該和不應該是什么樣。）

Answer 3

這看起來像一個用於在機櫃中組織OS目錄或manila文件的系統，而不是數據模型。 所以問題是，這種兩層結構的價值是什么？ 較高檔（121XX等）上有任何屬性或功能嗎？ 如果不是，則這僅是顯示問題，應照此處理。

另一方面，對於將（121XX，01）用作復合業務密鑰並將代理密鑰用作主密鑰，我沒有看到任何實質性的危害。 需要注意的一點是：如果銷售回升，您可能會達到10萬個訂單，這時訂單號將跳至六位數。 在大多數數據庫版本中，自然排序順序為：

100XX
1000XX
101XX