在我的一個數據庫類分配中，我寫道，我沒有特別指定長度作爲代理鍵的NUMBER列，因爲它會不必要地限制可以存儲在該表，因爲NUMBER（n）和NUMBER之間在性能或物理存儲方面幾乎沒有區別。使用指定替代鍵的長度
我的教授回憶說，對於大型數據庫來說，這在技術上是可行的，但是「不切實際」，而且大多數DBA在現實生活中不會這樣做。
就物理存儲或性能而言，NUMBER（n）和NUMBER之間沒有差別，因此沒有理由爲基於NUMBER的代理鍵列指定長度。爲什麼這位教授認爲單獨使用NUMBER將是「不切實際的」？
從可讀性和自我記錄的角度來看，它可能會更好，以限制可以存儲在列中的數字和預期的數字。我會同意，我看不到它的不切實際
數（n）是如何編輯 - 限制在長度爲n位數。
如果您存儲數字「55」，則它會在編號（38）中使用數字（2） 中的相同空格。
需要的存儲=實際存儲的數量的函數。
根據我的經驗，現實生活中的大多數生產DBA可能會按照您的建議進行操作，並將鍵列聲明爲NUMBER而不是NUMBER（n）。
向教授詢問是什麼讓這種方法在他或她看來不切實際是值得的。有幾種可能性，我可以想到
假設您正在使用數據建模工具來設計您的模式，一個合理的工具將確保一個密鑰的數據類型將在它所在的表中是相同的定義爲主鍵和子表中的外鍵。如果爲主鍵指定長度，則強制鍵生成沒有長度限制的外鍵將是不切實際的。當然，與此相反的是，您可以將主鍵和外鍵列都聲明爲NUMBER。
DBA往往是非常挑剔的（我的意思是這是一種恭維）。他們喜歡看到所有組織都「如此」。將長度限定符添加到字段，無論它是NUMBER還是VARCHAR2都充當隱式約束，以確保不正確的數據不會被存儲。理想情況下，當你設計一個表時，你會知道你在表的生命週期中插入的行數的合理上限（例如，如果你的PERSON表結束了超過100億行，那麼可能會出現嚴重錯誤） 。將長度約束應用於數字列向DBA表明您已經完成了這種分析。
但是，現在至少在數字列方面實際上不太可能發生，因爲它更符合瀑布規劃方法，這些方法通常涉及這種詳細的設計討論，並且因爲人們更少關注傳統上同時進行的增長分析。如果您在20年或30年前設計數據庫架構，向DBA提供每張表在上線和接下來幾年投影大小的逐個表格細分並不罕見。今天，在磁盤上花費更多，而不是花時間做前期分析的成本效益更高。
留給我自己的設備我會在oracle上代替NUMBER聲明代理主鍵爲NUMBER（38）。可能還有一個檢查約束條件，使關鍵字> 0.主要作爲外部系統的文檔，介紹他們在列中可以期待什麼以及他們需要處理什麼。
理論上，當構建讀取代理主鍵的應用程序時，看到NUMBER意味着需要處理完整的floating point range of number，而NUMBER（38）意味着應用程序需要處理最多38位數的整數。
如果我在一個所有前端將要使用32位整數替代鍵的環境中工作，我會用適當的檢查約束將其定義爲數字（10）。
此外，代理鍵通常會在鍵值中出現空洞，因此最大的代理鍵將大於表中保存的行數。對於指定序列中較大的緩存值以在RAC上獲得良好性能，情況尤其如此。因此，您不希望NUMBER（10）僅僅因爲您不希望處理超過（10e10）-1條記錄而需要。 –
@Shannon - 確實。但是，如果你有更多的漏洞比中等活躍的桌面上的數據漏洞更不可能，那麼即使我們每個人都註冊了4個人，你仍然可以安全地說世界上有60億人。還有數十億人還沒有出生，我們在行之間的平均差距爲5，但NUMBER（11）仍然足夠。 –
如果在輸出中使用代理鍵（例如作爲對應的參考號），我仍然會將最大尺寸放在上面，這樣您就可以明確地知道信件（或屏幕）中需要的空間）顯示該值。 –