問題描述
如果在我的表中的一列中，我希望值為 Yes、No 或 Optional，那么我需要使用什么數(shù)據(jù)類型?
If in one of my columns in my Table I want the values as either Yes, No or Optional then what data type do I need to use?
推薦答案
BIT:
- 占用 1 個字節(jié)，但在 SQL Server 中最多可以將 8 個 BIT 字段合并為一個 BYTE.
- 存儲兩個值之一:1(表示真)和 0(表示假)，因此該列需要可以為空，以便 NULL 作為您的第三個值傳遞
- 占用 1 個字節(jié)
- ASCII 不區(qū)分大小寫為 26 個字符，區(qū)分大小寫為 52 個字符
- 占用 1 個字節(jié)
- 值從 0 到 255
所有選項占用相同的空間量，使得 JOIN/etc 的性能相當.
All of the options take the same amount of space, making performance equivalent for JOINs/etc.
BIT 如果可能的值有任何變化的機會，則不是最明智的選擇.CHAR(1) 是立即可讀的 IE: Y, N, O.TINYINT 是您想要通過外鍵關聯(lián)的表中的主鍵的不錯選擇，并且將描述性文本存儲在另一列中.
BIT is not the wisest choice if there's any chance of the possible values changing. CHAR(1) is immediately readable IE: Y, N, O. TINYINT is a good choice for the primary key in a table you want to relate via foreign key, and store the descriptive text in another column.
CHAR(1) 將是我的選擇，否則 TINYINT.
使用 CHAR(1)，自然主鍵是單個字符的可能性很小.如果您有 2 個以上以相同字符開頭的單詞，則假設基于前導字符的自然鍵會失敗，并且如果標簽需要更改，則會導致悲傷，因為鍵也應該更改并永久保留(除非您很懶惰& 喜歡解釋為什么代碼不遵循與其他代碼相同的方案).CHAR(1) 還提供了 TINYINT 所做的大約五分之一的可能性(假設上限為 52 個區(qū)分大小寫的值)——人工/代理鍵與描述更改隔離.
CHAR(1) would be my choice if not using a foreign key relationship, TINYINT otherwise.
With CHAR(1), having a natural primary key that is a single character is very unlikely. Assuming a natural key based on the leading character fails if you have 2+ words that start with the same character, and causes grief if the label needs to change because the key should also change and be perpetuated (unless you're lazy & like explaining why a code doesn't follow the same scheme as the others). CHAR(1) also provides roughly a fifth of the possibilities (assuming the upper end, 52 case sensitive values) that TINYINT does -- the artificial/surrogate key insulates from description changes.
這篇關于關于選擇數(shù)據(jù)類型的文章就介紹到這了，希望我們推薦的答案對大家有所幫助，也希望大家多多支持html5模板網(wǎng)！