在數據庫中定義數據類型時，我總是遇到選擇是否使用整數或字符串來存儲某些「數值」數據的問題。整數與數據庫中的字符串
說我正在建設YetAnotherAddressBook並且有一個郵政編碼字段。假設郵政編碼是總是一個4位數字，哪種數據類型將它存儲爲？整數或字符串？從技術上講，這是一個整數，但我沒有對它進行任何計算，我只是把它吐在一張桌子上。如果我想通過郵政編碼對錶格進行排序，您的意見是否會發生變化？
現在，我不傻。我確實認識到整數的有效需求，例如頁面瀏覽量和唯一用戶或登錄用戶和訪客用戶。但是如何在torrent中存儲多少個文件呢？整數或字符串？
在我的國家，郵政編碼也總是4位數。但是第一個數字可以是零。
如果存儲「0700」作爲一個整數，你可以得到很多的問題：
從技術上講，我們的郵政編碼實際上是字符串，即使它總是4位數。
您可以將它們存儲爲整數，以節省空間。但請記住，這是一個簡單的數據庫技巧，並要小心前導零。
但是，如果要存儲多少個 文件在洪流中呢？整數或 字符串？
這很明顯是一個整數。
我認爲這取決於應用程序，列出如果您使用某個應用程序會得到什麼好處。我使用商店編號，他們是數字，但他們真的是一個字符串，因爲「00004」我想保持它的方式沒有格式化輸出，當我希望它是人類可讀的。當我保存它時，我會驗證它是否爲數字，然後將它保存爲字符串。我的缺點很可能是存儲大小，並且由於我在該領域有一個索引，所以它的性能可能會稍差，但我並不是100％。 – radtek 2014-04-30 17:33:13
郵政編碼是字符串。對於某些條目，這些字符串可能由數字組成，但這並不能使它們成爲整數。而且，你的保費系統遲早會用完數字並決定開始使用字母。如果您的數據庫使用整數作爲郵政編碼字段，那麼您將處於深度doo-doo。底線 - 如果你不做算術，它可能不是一個真正的數字。
對於郵政編碼，我會選擇一個字符串。它本質上不是一個整數。它只是某種東西的標識符，它也可能是一系列四個字符。
至於torrent內的文件數量，應該是一個整數。
'0000'是郵編嗎？它與'0'不同嗎？
如果它總是一個四位數字，我總是將它存儲爲4位數字，並且這將指向保持它爲一個字符串。
在我看來，對於郵政編碼，你必須使用字符串，因爲你可以讓郵政編碼與零（09100）保持一致，如果你使用整數，它將是9100：排序不是問題，因爲仍然存在字母順序（'09100'在'09101'之前）。 對於存儲文件編號我會期待一個整數，所以你沒有任何問題，在增加/減少它的數量。所以整數與字符串取決於你的使用！
這是一個語義問題。您正在嘗試爲存儲設定合適的數據類型，這可能是一個棘手的問題。如果您需要將數據作爲整數使用，最好的經驗法則是將數據存儲爲整數。
換句話說，由於您永遠不會將郵政編碼用作數字，因此將它作爲一個存儲是沒有意義的。不要緊，什麼樣的數據看起來像一樣，它重要的是它是。郵政編碼是數字嗎？不，這是一串恰好由全數字字符組成的字符。因此，郵政編碼最好以字符串形式存儲。
我不使用數字數據類型，除非我希望對數據進行數學運算。爲什麼冒險找到一個問題，在未來的某些你是「確定」將永遠是一個數字，有人決定把一個非數字字符英寸
如果你不打算做它的數學一個字符串。
的關鍵因素，恕我直言，是的applcation是否需要做的值數值算法計算，如果沒有，則使用一個整數的唯一原因是爲了減少存儲需求，（其中「可能」是很重要在關鍵應用中的性能 - 例如通過減小表索引的寬度以提高索引性能），但是否則通常並不重要...
如果不需要使用值進行算術運算，則字符串是最好的。
郵政編碼不是一個數字：它是一個代碼或標識符。這同樣適用於電話號碼。
洪流中的文件數量是一個整數。
的一點是，在這種情況下，你可以創建一個CHECK CONSTRAINT LIKE '[09][09][09][09]'保持正確的數據在數據庫級別。
還應該記住，並非所有國家的郵政編碼都只是數字。僅僅因爲你現在在加拿大沒有任何遺漏並不意味着你不會有任何東西。我總是被規則了，如果你想要做的數學計算其存儲在一個數字類型，如果它僅僅是一個代碼（postalcodes，電話，SSN，部分號碼等），然後我把它保存爲一個字符串。要避免什麼是數據的每次調用它（例如代碼添加前導零如果要存儲郵政編碼爲數字或代碼字符串轉換爲一個號碼calulations時間任何不必要的鑄造成另一種格式）。如果您需要重複執行這些操作，那麼這些操作可能是昂貴的操作，特別是當表格很大時，您最終不得不在where子句中執行轉換。以您需要的方式存儲數據要好得多。
我一直使用以下規則：
如果您計劃在其上進行數學運算（加法/減法/等），使其成爲一個整數或其他數字數據類型。
如果您不打算對該字段執行任何類型的數學計算，請將其存儲爲字符串。
在郵政編碼的例子中，你永遠不應該有一個時間你需要添加到一個郵政編碼，或減去或相乘兩個郵政編碼。郵政編碼通常不使用數學函數，因爲它們被用作標識符而不是數量。因此，你應該保存你的郵政編碼爲字符串數據類型
我完全同意並使用該理由。 +1 – Cerebrus 2009-04-14 16:20:53
那麼儘可能郵政編碼去，這是一個典型的英國郵政編碼：
EC2R 6PK
在我大學的數據庫講師告訴我的東西，一直堅持用我，仍然保留15年以上：
如果您對它執行算術運算，請將其作爲數字進行存儲。 它是一個數字。否則它是一個 字符串。
坦率地說，我不認爲你可以出錯的建議。
顯然你不對postcodes執行算術，因此它們是字符串。
如果你在關係數據庫如postgres/mysql或者甚至是mongodb nosql db中索引字段，在使用char over索引時會有什麼性能影響？那就是我所懷疑的。 – radtek 2014-04-30 17:34:32
Somtimes「always」的意思是「下個月」。在我的責任期內，我不會指望4位數字的代碼不會使用字母數字。
SQL的某些方言支持類似NUMBER（4）的數據類型。這很像一個字符串，但字母表是0到9.
即使您不希望對它執行數學運算，我也沒有看到將郵政編碼作爲數字存儲的問題。
在我們的企業數據倉庫中，我們是來自許多遺留系統的數據的接收者。結果，我們看到很多垃圾數據被使用。
以我們的情況爲例，我們有一個地理標識符是零填充的4位數字「數值」。該字段通常用於將表連接在一起。
我會採取兩種方法之一： 1）聲明列長度爲4的一個字符字段和添加約束LIKE '[09] [09] [09] [09]' 2）將其定義爲數字長度爲4，如果用戶需要，則只在「僅在顯示時顯示」格式。
方法數字1爲您節省了不斷格式化的麻煩，這沒什麼大不了的，但如果您經常過濾甚至索引/加入列，我會考慮說我們選擇了＃2選項。
第三個原因是我的經驗是，當向數據庫添加約束或者他們是無知時，人們只是懶惰。我個人認爲這更懶惰。我發現確實存在的約束主要應用於原始捕獲數據的應用程序中的編輯，而這些編輯並不均勻應用。
因此，我們的數據倉庫最終收到各種各樣的變化，包括與零值不一致的預填充或值的正當性。
將某些東西定義爲INTEGER時，會自動獲得更高效的存儲空間，在列上編制索引時，以及編輯每個人都能理解的內容，並且更有可能通過各種功能的數據庫設計人員在傳統系統中一致地應用。
我對選項＃1沒有任何問題，除了在索引中使用該字段以及我一度接受一個字段爲apha數字的方法之外，人們傾向於將更多的垃圾投入其中。
以我們的Peoplesoft員工標識爲例。有人決定在僱員面前添加一個「X」，填寫6個字符填入「數字」，以表明該員工是承包商。這違反了我個人的做法，不將單獨的信息組合成單個字段。這導致了各種系統中的各種不一致問題。如果這個字段是數字，沒有人會試圖這樣做。
評論？
瞭解您正在使用的數據的語義總是很重要的。讓我來解釋一下這個例子。
考慮你想在你的數據庫中存儲PIN碼。要回答你應該使用的數據類型，你必須回答什麼PIN（Personal identification number）的真正含義。
如果它真的是一個數字，因爲它的名字確實表明了我沒有看到任何理由，爲什麼它不應該被表示爲一個整數。
有些人可能會爭辯說，你不能區分0001和01.顯然他們不認爲PIN是一個數字，如果他們正在工作巫婆這樣的語義，他們應該使用字符串。
注意：如果PIN長度固定爲4位數字，他們仍然可以使用整數，因爲任何數字都將始終填充前導零並且會完全相同（0001將與01相同） - 但這些固定長度限制對於避免不正確輸入的數字是典型的。
如果語義清楚地表明PIN是一個數字，即PIN 0001與PIN 01完全相同，我將使用整數表示。
因此，在你的情況下，理解postal code語義是很重要的。這種語義在不同的國家會有所不同（甚至隨着時間的推移而改變），所以你想使用哪種語義也很重要。要覆蓋所有類型的郵政編碼，甚至可能的變化，我會考慮使用更抽象的數據類型或只是一個字符串（我相信已經包含更多的字符，不只是數字的語義）。
我不會推薦遵循簡化的規則，例如關於數據表示的算術運算的規則。如果你現在不想用數據進行數學運算並不意味着你將來有時候不會想要。
你有數據，你想存儲它，以某種方式表示 - 簡單地想想你在做什麼。
是的。我確實花了更多的時間格式化鏈接，而不是編寫實際的問題 – 2009-04-14 14:20:11