程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 數據庫知識 >> SqlServer數據庫 >> 關於SqlServer >> sql字段類型的說明

sql字段類型的說明

編輯:關於SqlServer
 

(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;?
4、不查詢的話沒什麼好說的,用nvarchar(4000)?
5、性格豪爽的可以只用3和4,偶爾用用1,畢竟這是一種額外說明,等於告訴別人說,我一定需要長度為X位的數據

 
  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved