The difference between CHAR, VARCHAR, TEXT and other fields in the database

When developers design databases, they often don't think much about char and varchar types, and some don't pay attention to them at all. Because storage prices are getting cheaper and cheaper, they forget some basic design theories and principles at the beginning. It reminds me of today's young people, who slip away from him with a big wave of RMB. In fact, I think whether it is a person or a developer, the grasp of the details directly determines many things. Of course, there are some people who simply don't know the difference between them, so they just choose one. Here I would like to make a simple analysis of them. Of course, if there is something wrong, I hope you can give me some advice.

1. CHAR . CHAR is very convenient to store fixed-length data, and the index on the CHAR field is highly efficient. For example, if you define char(10), then no matter whether the data you store reaches 10 bytes, it will take up 10 bytes of space. is automatically padded with spaces, so trim() may be used multiple times while reading .

2. VARCHAR . Store variable-length data , but the storage efficiency is not as high as CHAR. If the possible value of a field is not fixed length, we only know that it cannot exceed 10 characters, it is most cost-effective to define it as VARCHAR(10). The actual length of a VARCHAR type is the actual length of its value + 1. Why "+1"? This one byte is used to save how much length is actually used. Considering space, it is appropriate to use varchar; in terms of efficiency, it is appropriate to use char. The key is to find a trade-off point according to the actual situation.

3. TEXT . text stores variable-length non-Unicode data with a maximum length of 2^31-1 (2,147,483,647) characters.

4. NCHAR, NVARCHAR, NTEXT . These three have more "N" than the previous three in name. It indicates that the stored character is of Unicode data type. We know that among the characters, English characters only need one byte of storage, but there are many Chinese characters, which require two bytes of storage. When English and Chinese characters exist at the same time, it is easy to cause confusion. The Unicode character set is to solve the incompatibility of character sets. Because of the problem, all its characters are represented by two bytes, that is, English characters are also represented by two bytes. The length of nchar and nvarchar is between 1 and 4000. Compared with char and varchar, nchar and nvarchar can store up to 4000 characters, whether it is English or Chinese characters; while char and varchar can store up to 8000 English characters and 4000 Chinese characters. It can be seen that when using the nchar and nvarchar data types, there is no need to worry about whether the input characters are English or Chinese characters, which is more convenient, but there is some loss in the number of English storage.

So in general, if it contains Chinese characters, use nchar/nvarchar, if it is pure English and numbers, use char/varchar

. The difference is summarized as:
CHAR, NCHAR fixed length, fast speed, large space, need to deal with
VARCHAR, NVARCHAR, TEXT variable length, small space, slow speed, no need to process
NCHAR, NVARCHAR, NTEXT to process Unicode code
 
Find a piece of information below, source http://wenku.baidu.com/view/eee97bf5f61fb7360b4c652b.html
 
Varchar uses single byte to store data in SQL Server, and nvarchar uses Unicode to store data. Chinese characters are stored in SQL Server as two bytes (usually Unicode encoding), English characters are stored in the database, if the field type is varchar , it will only occupy one byte , and if the field type is nvarchar , it will occupy two bytes
  Under normal circumstances, we can also use varchar
to store Chinese characters , but if the operating system is an English operating system and the support for Chinese fonts is not comprehensive , garbled characters (displayed as ?? ). And under normal circumstances, the host will support the Chinese environment, so if you use varchar to store data, you can't find it in the development stage. In most cases, of course, using nvarchar
  
to store English characters will double the storage space. But in the case where storage is already cheap, prioritizing compatibility will give you more benefits. Therefore, when designing, you should try to use nvarchar to store data. Only use varchar to store when you ensure that the field will not save Chinese. When there is no problem.
  
  但是!如果布署的主机是英文操作系统,并且不支持中文环境,那问题就出来了.所有的varchar字段在存储中文的时候都会变成乱码(显示为??).而且一般情况下你不会知道这是因为你采用了错误的数据类型来存储所造成的,你会试着去装中文字体,试着去设置操作系统的语言环境...这些都不能解决问题,唯一能解决问题的是把数据库字段的类型个性为nvarchar(或者nchar).对项目管理比较熟悉的朋友应该都知道,到布署阶段再来修改数据库是一个很恐怖的事情.
  使用nvarchar的另一个非常好处就是在判断字符串的时候可以不需要考虑中英文两种字符的差别.

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=326450877&siteId=291194637