為什么要使用較短的VARCHAR（n）字段？

Question

通常建議選擇盡可能窄的數據庫字段大小。 我想知道這適用於SQL Server 2005 VARCHAR列的程度：在VARCHAR(255)字段中存儲10個字母的英文單詞不會占用比VARCHAR(10)字段更多的存儲空間。

是否有其他原因限制VARCHAR字段的大小盡可能貼近數據的大小？ 我在想

• 性能：在選擇，過濾和排序數據時使用較小的n是否有優勢？
• 內存，包括在應用程序端（C ++）？
• 樣式/驗證：您認為限制colunm大小以強制非敏感數據導入失敗（例如200個字符的姓氏）有多重要？
• 還要別的嗎？

背景：我幫助數據集成商將數據流的設計流入數據庫支持的系統。 他們必須使用限制他們選擇的數據類型的API。 對於字符數據，只有n <= 255的VARCHAR(n)可用; CHAR ， NCHAR ， NVARCHAR和TEXT不是。 我們試圖制定一些“良好實踐”規則，如果使用VARCHAR(255)甚至對實際最大大小永遠不會超過30個字節的數據存在真正的損害，那么問題就出現了。

一個表的典型數據量是1-10 Mio記錄，最多150個屬性。 查詢性能（ SELECT ，具有頻繁擴展的WHERE子句）和應用程序端檢索性能是至關重要的。

Answer 1

1. 數據完整性 - 迄今為止最重要的原因。 如果您創建一個名為Surname 255個字符，那么您可能會獲得的不僅僅是姓氏。 你會得到名字，姓氏，中間名。 你會得到他們最喜歡的寵物。 你會得到“會計部門的Alice和三角形的頭發”。 簡而言之，您將使用戶可以輕松地將該列用作notes / surname列。 您希望上限阻止嘗試將除姓氏之外的內容放入該列的用戶。 如果您有一個要求特定長度的列（例如，美國稅收標識符是九個字符）但列是varchar(255) ，那么其他開發人員會想知道發生了什么， 並且您可能也會獲得垃圾數據。

2. 索引和行限制。 在SQL Server中，您的IIRC限制為8060字節。 有大量數據的大量非varchar（max）列很快就會超出該限制。 此外，索引的寬度為IIRC，上限為900字節。 因此，如果您想對您的姓氏列和其他包含大量數據的列進行索引，則可能會超出此限制。

3. 報告和外部系統。 作為報表設計者，您必須假設如果聲明列的最大長度為255，則可以包含255個字符。 如果用戶可以這樣做，他們就會這樣做。 因此，要說“它可能不會有超過30個字符。” 甚至與“它不能超過30個字符”相同。 永遠不要依賴前者。 作為報表設計者，您必須解決用戶將大量數據輸入列的可能性。 這要么意味着截斷值（如果是這樣的話，為什么還有額外的空間可用？）或者使用CanGrow來制作一個可愛的報告。 無論哪種方式，如果列大小遠遠超出存儲的實際數據，那么在其他開發人員上更難理解列的意圖。

Answer 2

我認為最大的問題是數據驗證。 如果您為姓氏允許255個字符，您將獲得數據庫中200多個字符的姓氏。

另一個原因是，如果您允許數據​​庫保存255個字符，則現在必須在觸及數據庫的每個系統中考慮這種可能性。 例如，如果您導出到固定寬度的列文件，則所有列的寬度必須為255個字符，這可能非常煩人甚至有問題。 這只是一個可能導致問題的例子。

Answer 3

一個很好的理由是驗證。

（例如）在荷蘭，社會安全號碼總是9個字符長，當你不允許更多它永遠不會發生時。

如果你允許更多，並且由於一些未知的原因，有10個字符，你將需要檢查（否則你不會）檢查它是否長9。

Answer 4

另一件事是單行數據限制為8060字節，SQL Server使用varchar字段的最大長度來確定這一點。

參考： http ： //msdn.microsoft.com/en-us/library/ms143432.aspx

Answer 5

1）可讀性和支持

數據庫開發人員可以查看名為StateCode的字段，其長度為varchar（2），並且可以很好地了解該字段所包含的數據類型，甚至無需查看內容。

2）報告

當數據沒有長度約束時，您希望開發人員強制列數據的長度相似。 在報告該數據時，如果開發人員未能使列數據保持一致，那么將使報告數據不一致並且看起來很有趣。

3）SQL Server數據存儲

SQL Server將數據存儲在8k“頁面”上，從性能角度來看，盡可能高效地存儲數據並在頁面上存儲盡可能多的數據是理想的。

如果您的數據庫被設計為將每個字符串列存儲為varchar（255），則“錯誤”數據可能會滑入其中一個字段（例如，狀態名稱可能會滑入一個意味着長度為2個字符的StateCode字段），並且導致不必要的低效頁面和索引拆分。