SQL Server資料庫欄位資料類型

bit
整型
bit 資料類型是整型，其值只能是0、1或空值。這種資料類型用於儲存只有兩種可能值的資料，如Yes 或No、True 或Fa lse
、On 或Off

int
整型
int 資料類型可以儲存從- 231(-2147483648)到231 (2147483
647)之間的整數。儲存到資料庫的幾乎所有數值型的資料都可以用這種資料類型。這種資料類型在資料庫裡佔用4個位元組

smallint
整型
smallint
資料類型可以儲存從-
215(-32768)到215(32767)之間的整數。這種資料類型對儲存一些常限定在特定範圍內的數值型資料非常有用。這種資料類型在資料庫裡佔用2
位元組空間

tinyint
整型
tinyint 資料類型能儲存從0到255
之間的整數。它在你只打算儲存有限數目的數值時很有用。 這種資料類型在資料庫中佔用1
個位元組

numeric
精確數值型
numeric資料類型與decimal
型相同

decimal
精確數值型
decimal
資料類型能用來儲存從-1038-1到1038-1的固定精度和範圍的數值型資料。使用這種資料類型時，必須指定範圍和精度。範圍是小數點左右所能儲存的數位總位元。精度是小數點右邊儲存的數位位元

money
貨幣型
money
資料類型用來表示錢和貨幣值。這種資料類型能儲存從-9220億到9220
億之間的資料，精確到貨幣單位的萬分之一

smallmoney
貨幣型
smallmoney
資料類型用來表示錢和貨幣值。這種資料類型能儲存從-214748.3648 到214748.3647
之間的資料，精確到貨幣單位的萬分之一

float
近似數值型
float
資料類型是一種近似數實值型別，供浮點數使用。說浮點數是近似的，是因為在其範圍內不是所有的數都能精確表示。浮點數可以是從-1.79E+308到1.79E+308
之間的任意數

real
近似數值型
real
資料類型像浮點數一樣，是近似數實值型別。它可以表示數值在-3.40E+38到3.40E+38之間的浮點數

datetime
日期時間型
datetime資料類型用來表示日期和時間。這種資料類型儲存從1753年1月1日到9999年12月3
1日間所有的日期和時間資料，精確到三百分之一秒或3.33毫秒

Smalldatetime
日期時間型
smalldatetime
資料類型用來表示從1900年1月1日到2079年6月6日間的日期和時間，精確到一分鐘

cursor
特殊資料型
cursor
資料類型是一種特殊的資料類型，它包含一個對遊標的引用。這種資料類型用在預存程序中，而且建立表時不能用

timestamp
特殊資料型
timestamp
資料類型是一種特殊的資料類型，用來建立一個資料庫範圍內的唯一數位。一個表中只能有一個timestamp列。每次插入或修改一行時，timestamp列的值都會改變。儘管它的名字中有“time”，但timestamp列不是人們可識別的日期。在一個資料庫裡，timestamp值是唯一的

Uniqueidentifier
特殊資料型
Uniqueidentifier資料類型用來儲存一個通用唯一識別碼，即GUID。GUID確實是全域唯一的。這個數幾乎沒有機會在另一個系統中被重建。可以使用NEWID
函數或轉換一個字串為唯一識別碼來初始化具有唯一識別碼的列

char
字元型
char資料類型用來儲存指定長度的定長非統一編碼型的資料。當定義一列為此類型時，你必須指定列長。當你總能知道要儲存的資料的長度時，此資料類型很有用。例如，當你按郵遞區號加4個字元格式設定來儲存資料時，你知道總要用到10個字元。此資料類型的列寬最大為8000
個字元

varchar
字元型
varchar資料類型，同char類型一樣，用來儲存非統一編碼型字元資料。與char
型不一樣，此資料類型為變長。當定義一列為該資料類型時，你要指定該列的最大長度。它與char資料類型最大的區別是，儲存的長度不是列長，而是資料的長度

text
字元型
text
資料類型用來儲存大量的非統一編碼型字元資料。這種資料類型最多可以有231-1或20億個字元

nchar
統一編碼字元型
nchar
資料類型用來儲存定長統一編碼字元型資料。統一編碼用雙位元組結構來儲存每個字元，而不是用單位元組(普通文本中的情況)。它允許大量的擴充字元。此資料類型能儲存4000種字元，使用的位元組空間上增加了一倍

nvarchar
統一編碼字元型
nvarchar
資料類型用作變長的統一編碼字元型資料。此資料類型能儲存4000種字元，使用的位元組空間增加了一倍

ntext
統一編碼字元型
ntext
資料類型用來儲存大量的統一編碼字元型資料。這種資料類型能儲存230
-1或將近10億個字元，且使用的位元組空間增加了一倍

binary
位元據類型
binary資料類型用來儲存可達8000
位元組長的定長的位元據。當輸入表的內容接近相同的長度時，你應該使用這種資料類型

varbinary
位元據類型
varbinary
資料類型用來儲存可達8000
位元組長的變長的位元據。當輸入表的內容大小可變時，你應該使用這種資料類型

image
位元據類型
image
資料類型用來儲存變長的位元據，最大可達231-1或大約20億位元組

1)char、varchar、text和nchar、nvarchar、ntext
char和varchar的長度都在1到8000之間，它們的區別在於char是定長字元資料，而varchar是變長字元資料。所謂定長就是長度固定的，當輸入的資料長度沒有達到指定的長度時將自動以英文空格在其後面填充，使長度達到相應的長度；而變長字元資料則不會以空格填充。text儲存可變長度的非Unicode資料，最大長度為2^31-1(2,147,483,647)個字元。

後面三種資料類型和前面的相比，從名稱上看只是多了個字母"n"，它表示儲存的是Unicode資料類型的字元。寫過程式的朋友對Unicode應該很瞭解。字元中，英文字元只需要一個位元組儲存就足夠了，但漢字眾多，需要兩個位元組儲存，英文與漢字同時存在時容易造成混亂，Unicode字元集就是為瞭解決字元集這種不相容的問題而產生的，它所有的字元都用兩個位元組表示，即英文字元也是用兩個位元組表示。nchar、nvarchar的長度是在1到4000之間。和char、varchar比較：nchar、nvarchar則最多儲存4000個字元，不論是英文還是漢字；而char、varchar最多能儲存8000個英文，4000個漢字。可以看出使用nchar、nvarchar資料類型時不用擔心輸入的字元是英文還是漢字，較為方便，但在儲存英文時數量上有些損失。

(2)datetime和smalldatetime
datetime：從1753年1月1日到9999年12月31日的日期和時間資料，精確到百分之三秒。
smalldatetime：從1900年1月1日到2079年6月6日的日期和時間資料，精確到分鐘。

(3)bitint、int、smallint、tinyint和bit
bigint：從-2^63(-9223372036854775808)到2^63-1(9223372036854775807)的整型資料。
int：從-2^31(-2,147,483,648)到2^31-1(2,147,483,647)的整型資料。
smallint：從-2^15(-32,768)到2^15-1(32,767)的整數資料。
tinyint：從0到255的整數資料。
bit：1或0的整數資料。

(4)decimal和numeric
這兩種資料類型是等效的。都有兩個參數：p（精度）和s（小數位元）。p指定小數點左邊和右邊可以儲存的十進位數位最大個數，p必須是從
1到38之間的值。s指定小數點右邊可以儲存的十進位數位最大個數，s必須是從0到p之間的值，預設小數位元是0。

(5)float和real
float：從-1.79^308到1.79^308之間的浮點數字資料。
real：從-3.40^38到3.40^38之間的浮點數字資料。在SQL
Server中，real的同義字為float(24)。

資料庫定義到char類型的欄位時，不知道大家是否會猶豫一下，到底選char、nchar、varchar、nvarchar、text、ntext中哪一種呢？結果很可能是兩種，一種是節儉人士的選擇：最好是用定長的，感覺比變長能省些空間，而且處理起來會快些，無法定長只好選用定長，並且將長度設定儘可能地小；另一種是則是覺得無所謂，盡量用可變類型的，長度盡量放大些。

鑒於現在硬體像蘿蔔一樣便宜的大好形勢，糾纏這樣的小問題實在是沒多大意義，不過如果不弄清它，總覺得對不起勞累過度的CPU和硬碟。

下面開始了(以下說明只針對SqlServer有效)：

1、當使用非unicode時慎用以下這種查詢：
select
f from t where f =
N'xx'

原因：無法利用到索引，因為資料庫會將f先轉換到unicode再和N'xx'比較

2、char
和相同長度的varchar處理速度差不多（後面還有說明）

3、varchar的長度不會影響處理速度！！！（看後面解釋）

4、索引中列總長度最多支援總為900位元組，所以長度大於900的varchar、char和大於450的nvarchar,nchar將無法建立索引

5、text、ntext上是無法建立索引的

6、O/R
Mapping中對應實體的屬性類型一般是以string居多，用char[]的非常少，所以如果按mapping的合理性來說，可變長度的類型更加吻合

7、一般基礎資料表中的name在實際查詢中基本上全部是使用like
'%xx%'這種方式，而這種方式是無法利用索引的，所以如果對於此種欄位，索引建了也白建

8、其它一些像remark的欄位則是根本不需要查詢的，所以不需要索引

9、varchar的存放和string是一樣原理的，即length
{block}這種方式，所以varchar的長度和它實際佔用空間是無關的

10、對於固定長度的欄位，是需要額外空間來存放NULL標識的，所以如果一個char欄位中出現非常多的NULL，那麼很不幸，你的佔用空間比沒有NULL的大（但這個大並不是大太多，因為NULL標識是用bit存放的，可是如果你一行中只有你一個NULL需要標識，那麼你就白白浪費1byte空間了，罪過罪過！），這時候，你可以使用特殊標識來存放，如：'NV'

11、同上，所以對於這種NULL查詢，索引是無法生效的，假如你使用了NULL標識替代的話，那麼恭喜你，你可以利用到索引了

12、char和varchar的比較成本是一樣的，現在關鍵就看它們的索引尋找的成本了，因為尋找策略都一樣，因此應該比較誰佔用空間小。在存放相同數量的字元情況下，如果數量小，那麼char佔用長度是小於varchar的，但如果數量稍大，則varchar完全可能小於char，而且要看實際填充數值的充實度，比如說varchar(3)和char(3)，那麼理論上應該是char快了，但如果是char(10)和varchar(10)，充實度只有30%的情況下，理論上就應該是varchar快了。因為varchar需要額外空間存放塊長度，所以只要length(1-fillfactor)大於這個存放空間（好像是2位元組)，那麼它就會比相同長度的char快了。

13、nvarchar比varchar要慢上一些，而且對於非unicode字元它會佔用雙倍的空間，那麼這麼一種類型推出來是為什麼呢？對，就是為了國際化，對於unicode類型的資料，定序對它們是不起作用的，而非unicode字元在處理不同語言的資料時，必須指定定序才能正常工作，所以n類型就這麼一點好處。

總結：
1、如果資料量非常大，又能100%確定長度且儲存只是ansi字元，那麼char
2、能確定長度又不一定是ansi字元或者，那麼用nchar；
3、不確定長度，要查詢且希望利用索引的話，用nvarchar類型吧，將它們設到400；