數據庫表列數據類型設計問題

有時候，一個數據可以表示爲一個整數（4字節）或一個字符串。示例：電話號碼爲bigint（8字節），郵政編碼爲int（4）等。我們有一個索引值描述三元組的大表格作爲3列，索引是5位整數（不是順序的），以及我們把它作爲int。 DBA告訴我們這是一個糟糕的設計，應該總是使用varchar來保存這些數據，除非它可以是像auto-inc PK那樣的保證整數。你同意嗎？爲什麼或者爲什麼不？數據庫表列數據類型設計問題

來源

2011-01-26 Manidip Sengupta

我會建議不要使用VARCHAR作爲索引列，如果你所需要做的只是表示一個id。首先，索引VARCHAR會有不必要的處理開銷。這種開銷來自這樣一個事實，即在比較索引目的之前，必須通過數據庫COLLATION對VARCHAR值進行轉換。其次，沒有理由擁有可變長度的數據類型 - 這會導致索引效率低下。第三，你需要5倍的空間來表示一個整數作爲VARCHAR而不是INT。這意味着使用VARCHAR的索引最多會大5倍。最後，數字數據總是會潛入列中。這可能會影響您的索引並可能破壞數據庫的參照完整性。

來源

2011-01-26 21:54:45 ThomasMcLeod

這就是爲什麼我們首先選擇整數 - 使用內存（不知道它需要5倍，但）。插入語句由servlet方法生成，而非數字數據會引發相關的異常。所以我們主要關心的是（1）內存使用和（2）效率 - 我們需要ResultSet.getInt（「id」）而不是Integer.parseInt（ResultSet.getString（「id」））。 – 2011-01-27 00:04:24

NVARCHAR是Unicode版本的5倍，否則是2.5倍。 – ThomasMcLeod 2011-01-27 02:32:04

我的經驗法則是，如果您不打算對其進行數學計算，並且它不是代理鍵的代理鍵或fk，則它是字符串數據。電話號碼不是整數，它們是字符串，與郵政編碼相同（在美國以外，它們並不總是數字）。以字符串形式存儲的數字通常具有並需要前導零（請參閱美國郵政編碼）將它們存儲爲INT或小數不會讓您輸入有效值。如果它不是自動生成的，你怎麼知道它需要是整數數據？如果你是100％肯定的，它應該永遠不會是除了整數之外的任何東西（並且沒有前導零），使它成爲一個int將防止一些不良數據進入。但是，真的很確定，你不需要做它稍後將字符串數據（例如當您國際化並找出您的posal代碼不再是數字時）。

爲了給你提供更好的建議，我需要一個更好的你正在談論的數據類型的例子。您的表格數據需求並不完全清楚。

來源

2011-01-26 20:22:20 HLGEM

他的陳述主要是用電話號碼和郵政編碼 - 我們使用電話號碼的數字來組成整數 - 3 /地區代碼，7 /數字和5 /擴展 - 15位數字。一些檢查工作就像areacode> = 200等。Zip <5位數 - 我們預先設置0來使其成爲5.我們知道這不是國際性的，但我們正在爲美國客戶羣開發。但我喜歡你的經驗法則，不得不咀嚼一點。 – 2011-01-26 23:56:39

如果DB是oracle，DBA可能是正確的。對於分區和索引，VARCHAR2類型比INT更高效。

另外，如果你不會在INT字段上進行聚合或類似的事情，那麼沒有收穫。

來源

2011-01-26 22:26:17 Uordek

數據庫表列數據類型設計問題

回答

相關問題