Home >Database >Mysql Tutorial >sqlserver中char转化为varchar出现的问题

sqlserver中char转化为varchar出现的问题

WBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWB
WBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOriginal
2016-06-07 15:34:092369browse

Users 数据库下 create table other_user ( id int identity ( 1 , 1 ) primary key not null, name varchar ( 30 ), pass varchar ( 30 ), university char ( 20 ), qq char ( 20 )); 这里我让 id 号自动增加。 我插入第一条数据记录: insert into other_u


Users数据库下

create table other_user (

    id int identity(1,1) primary key not null,

    name varchar(30),

    pass varchar(30),

    university char(20),

qq char(20));

这里我让id号自动增加。

我插入第一条数据记录:insert into other_user values('zhb','123','bnu','8888');作为登录验证

我一开始存储密码pass,这里是(‘123’),用的是varchar格式的,可以完成登录验证;但是后来

我用这条语句alter table other_user alter column pass char(10);

换成了char(10)数据类型的时候就不行了,应该是用char的时候(定长的原因)出现了多余的空格,所以在rs.getString(“pass”).equals(pass)的时候为false,所以登录验证不了。此时的passchar(10)类型的,更奇怪的是:我将pass的数据类型还原成原来的varchar(30)的时候,

alter table other_user alter column pass varchar(30);

再次使用之前的表中的那条记录进行登录验证,结果是登录不了。这是为什么了?

   还没有结束,pass的数据类型还原之后,我再往表中插入一条数据,

insert into other_user values('bhz','321','bnu','8888');

对这条数据记录进行登录验证就可以了,奇怪了,难道是转换数据类型的时候,原来的数据所占的空间是不变的(从我这里来看,varchar变成char出现多余的空格,而char变成varchar是不是还保留着原来的空格呢?)。

这里使用charvarchar的时候要小心。

以下是我从其他地方找来的资料,本来想标注一下资料的处处,但是看到网上有太多是copy,鱼目混杂,也不知道谁是原创的,所以请原创者多多包含,也谢谢你的分享

 1.char的长度是固 定的,而VARCHAR2的长度是可以变化的, 比如,存储字符串“abc",对于char (20),表示你存储的字符将占20个字节(包括17个空字符),而同样的varchar2 (20)则只占用3个字节的长度,20只是最大值,当你存储的字符小于20时,按实际长度存储。由于char是以固定长度的,所以它的速度会比 varchar快得多!但程序处理起来要麻烦一点,要用trim之类的函数把两边的空格去掉!

2.char的效率比varchar2的效率稍高。

3.目前VARCHARVARCHAR2的同义词。工业标准的VARCHAR类型可以存储空字符串,但是oracle不这样做,尽管它保留以后这样做的权利。Oracle自己开发了一个数据类型VARCHAR2,这个类型不是一个标准的VARCHAR,它将在数据库中varchar列可以存储空字符串的特性改为存储NULL值。如果你想有向后兼容的能力,Oracle建议使用VARCHAR2而不是VARCHAR

何时该用CHAR,何时该用varchar2? 
CHARVARCHAR2是一对矛盾的统一体,两者是互补的关系
VARCHAR2CHAR节省空间,在效率上比CHAR会稍微差一些,即要想获得效率,就必须牺牲一定的空间,这也就是我们在数据库设计上常说的‘以空间换效率’。 
VARCHAR2 虽然比CHAR节省空间,但是如果一个VARCHAR2列经常被修改,而且每次被修改的数据的长度不同,这会引起‘行迁移’(Row Migration)现象,而这造成多余的I/O,是数据库设计和调整中要尽力避免的,在这种情况下用CHAR代替VARCHAR2会更好一些。

一般地说,只要一个表有一个字段定义为varchar(n)类型,那么其余用char(n)定义的字段实际上也是varchar(n)类型。 

如果你的长度本身不长,比如就310个字符,那么使用char(n)格式效率比较高,搜索速度快。但是如果有的数据很长,有的数据有比较短,比如注册用户的简介这样的字段,实在没有办法,而且很在乎浪费的空间,那么就用varchar(n)格式。


Char,varchar,nvarchar字段是sql server数据库中的三种字段类型。好多人在选择存储的时候不知道如何抉择,我给大家讲下这个三个字段类型的区别。 Char(n)是长度为n个字节的定长的非unicode的字符数据。N为一个介于18000之间的值。其存储大小为输入数据的实际字节长度,而不是n个字节。如果你输入的实际字节长度少于n,那么其他位置会被空格填充。在数据存储中英文字母和数字占一个字节,汉字占两个字节。那么char(n)最多可以存储n个英文字母或数字,或者n/2个汉字。 Varchar(n)是长度为个字节的可变长度且非 Unicode 的字符数据。必须是一个介于8,000 之间的数值。存储大小为输入数据的字节的实际长度,而不是 个字节。注意它和char(n)的区别是char(n)是定长的,varchar(n)是变长的。

如果你输入的字符的实际字节长度少于n,那么它的长度就是你实际输入的字节长度。在数据存储中英文字母和数字占一个字节,汉字占两个字节。Varchar(n)最多可以存储n个英文字母或数字,或者n/2个汉字。 Nvarchar(n) 包含 个字符的可变长度 Unicode 字符数据。的值必须介于 与 4,000 之间。字节的存储大小是所输入字符个数的两倍在数据存储中英文字母,数字,汉字都是占两个字节。Char(n)最多可以存储n个英文字母或数字,或者n个汉字。

 在数据检索中,一般来说char型字段的数据是最快的,varchar,nvarchar型字段其次。 在所存数据长度不一的情况下,varcahr型字段所占空间最少,char,nvarchar其次。 那么到底在什么样的情况下使用什么样的数据类型那? 如果你所存数据长度基本一致,建议使用char型。这样检索速度快,但是提取的时候要注意用trim()函数剔除所存数据两边的空格。 如果你所存数据长度差异较大,可以使用varchar或者nvarchar。如果你想较好的支持多语言的话,最好使用nvarchar。使用nvarchar可以减少字符转换问题,防止某些情况下乱码的出现。

说了这么多,大家可能都晕了。列个表供大家参考。 Char(n) Varchar(n) Nvarchar(n) N 最大值 8000 8000 4000 数据长度固定(不足用空格填充)可变(实际数据长度)可变(实际数据长度)可存储最多英文(数字) 8000 8000 4000 最多汉字数 4000 4000 4000 英文(数字)所占字节 1 1 2 汉字所占字节 2 2 2 检索速度快慢慢在去年的一个网站项目中,我使用了sql server数据库,数据库排序规则为Chinese_PRC_CI_AS.其中部分字段使用varchar型。

我在本机浏览数据库中数据正常,页面数据显示正常。但是当我将数据库导入到服务器以后,在客户端发现页面从数据库中读取的数据显示全是乱码。我通过查询分析器连接到服务器,发现数据库中的汉字也全变成了乱码。 我估计服务器端sql server为英文版,于是将服务器数据库中varchar型字段都改为nvarchar型,乱码问题解决。但是同时我又发现一个奇怪的现象。

比如数据库中有两个记录。 表名: ComputerInfo Computer computerType 成都家具厂 私营 合肥家具厂 私营 其中Computer字段为nvarchar型。我用 select * from ComputerInfo where Computer like %成都%’ 返回的记录数总是0.奇怪了,明明数据库中有数据的嘛。我查阅了大量的资料以后,终于解决了问题。只需要把查询语句改为select * from ComputerInfo where Computer like N%成都%’ 即可。在字符前加N表示将其转化为unicode字符。原文出自:http://www.cnblogs.com/shuang121/archive/2011/03/19/1988794.html



Statement:
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn