精华内容
下载资源
问答
  • 对于程序中string型字段,SQLServer中有char、varchar、nchar、nvarchar四种类型来对应(暂时不考虑textntext),开建立数据库中,对这四种类型往往比较模糊,这里做一下对比。 1.有var前缀,表示是实际...

    本文摘自:http://blog.csdn.net/tongailing/article/details/6294617

    对于程序中的string型字段,SQLServer中有char、varchar、nchar、nvarchar四种类型来对应(暂时不考虑text和ntext),开建立数据库中,对这四种类型往往比较模糊,这里做一下对比。

    1.有var前缀的,表示是实际存储空间是变长的,varchar,nvarchar
    所谓定长就是长度固定的,当输入的数据长度没有达到指定的长度时将自动以英文空格在其后面填充,使长度达到相应的长度;而变长字符数据则不会以空格填充,比较例外的是,text存储的也是可变长。

    2.n表示Unicode字符,即所有字符都占两个字节,nchar,nvarchar
    字符中,英文字符只需要一个字节存储就足够了,但汉字众多,需要两个字节存储,英文与汉字同时存在时容易造成混乱,Unicode字符集就是为了解决字符集这种不兼容的问题而产生的,它所有的字符都用两个字节表示,即英文字符也是用两个字节表示。

    3.基于以上两点来看看字段容量

    char,varchar

    最多8000个英文,4000个汉字

    nchar,nvarchar

    可存储4000个字符,无论英文还是汉字

    4.使用(个人偏好)
          a.如果数据量非常大,又能100%确定长度且保存只是ansi字符,那么char
          b.能确定长度又不一定是ansi字符或者,那么用nchar;
          c.对于超大数据,如文章内容,使用nText
          d.其他的通用nvarchar

    特点比较

    1、CHAR。CHAR存储定长数据很方便,CHAR字段上的索引效率级高,比如定义char(10),那么不论你存储的数据是否达到了10个字节,都要占去10个字节的空间。

    2、VARCHAR。存储变长数据,但存储效率没有CHAR高,如果一个字段可能的值是不固定长度的,我们只知道它不可能超过10个字符,把它定义为 VARCHAR(10)是最合算的。VARCHAR类型的实际长度是它的值的实际长度+1。为什么"+1"呢?这一个字节用于保存实际使用了多大的长度。

    从空间上考虑,用varchar合适;从效率上考虑,用char合适,关键是根据实际情况找到权衡点。

    3、TEXT。text存储可变长度的非Unicode数据,最大长度为2^31-1(2,147,483,647)个字符。

    4、NCHAR、NVARCHAR、NTEXT。这三种从名字上看比前面三种多了个"N"。和char、varchar比较起来,nchar、nvarchar最多存储4000个字符,不论是英文还是汉字;而char、varchar最多能存储8000个英文,4000个汉字。可以看出使用nchar、nvarchar数据类型时不用担心输入的字符是英文还是汉字,较为方便,但在存储英文时数量上有些损失。

    所以一般来说,如果含有中文字符,用nchar/nvarchar,如果纯英文和数字,用char/varchar。

    展开全文
  • 数据库char和nchar的区别

    千次阅读 2014-10-24 10:05:22
    char 类型是一个字节 char(8)只能存8字母 nchar 类型是双字节 nchar(8)能存8个汉字
    char 类型是一个字节 char(8)只能存8字母 nchar  类型是双字节 nchar(8)能存8个汉字
    
    展开全文
  • "sqlserver里面有char和nchar,那个n据说是指unicode数据,这个是什么意思。"  并不是所有简单问题都很容易回答,就像这个问题一样。于是我答应专门写一篇BLOG来从头讲讲编码故事。那么就让我们找个草堆坐下...

          "sqlserver里面有char和nchar,那个n据说是指unicode的数据,这个是什么意思。"

           并不是所有简单的问题都很容易回答,就像这个问题一样。于是我答应专门写一篇BLOG来从头讲讲编码的故事。那么就让我们找个草堆坐下,先抽口烟,看看夜晚天空上的银河,然后想一想要从哪里开始讲起。嗯,也许这样开始比较好……大笑一定要细心看完哦,绝对有收获的

         很久很久以前,有一群人,他们决定用8个可以开合的晶体管来组合成不同的状态,以表示世界上的万物。他们看到8个开关状态是好的,于是他们把这称为"字节"。睡觉


          再后来,他们又做了一些可以处理这些字节的机器,机器开动了,可以用字节来组合出很多状态,状态开始变来变去。他们看到这样是好的,于是它们就这机器称为"计算机"。睡觉

         开始计算机只在美国用。八位的字节一共可以组合出256(2的8次方)种不同的状态。惊讶

          他们把其中的编号从0开始的32种状态分别规定了特殊的用途,一但终端、打印机遇上约定好的这些字节被传过来时,就要做一些约定的动作。遇上00x10, 终端就换行,遇上0x07, 终端就向人们嘟嘟叫,例如遇上0x1b, 打印机就打印反白的字,或者终端就用彩色显示字母。他们看到这样很好,于是就把这些0x20以下的字节状态称为"控制码"。

         他们又把所有的空格、标点符号、数字、大小写字母分别用连续的字节状态表示,一直编到了第127号,这样计算机就可以用不同字节来存储英语的文字了。大家看到这样,都感觉很好,于是大家都把这个方案叫做 ANSI 的"Ascii"编码(AmericanStandard Code for Information Interchange,美国信息互换标准代码)。当时世界上所有的计算机都用同样的ASCII方案来保存英文文字。生气

         后来,就像建造巴比伦塔一样,世界各地的都开始使用计算机,但是很多国家用的不是英文,他们的字母里有许多是ASCII里没有的,为了可以在计算机保存他们的文字,他们决定采用127号之后的空位来表示这些新的字母、符号,还加入了很多画表格时需要用下到的横线、竖线、交叉等形状,一直把序号编到了最后一个状态255。从128到255这一页的字符集被称"扩展字符集"。从此之后,贪婪的人类再没有新的状态可以用了,美帝国主义可能没有想到还有第三世界国家的人们也希望可以用到计算机吧!生气

         等中国人们得到计算机时,已经没有可以利用的字节状态来表示汉字,况且有6000多个常用汉字需要保存呢。但是这难不倒智慧的中国人民,我们不客气地把那些127号之后的奇异符号们直接取消掉, 规定:一个小于127的字符的意义与原来相同,但两个大于127的字符连在一起时,就表示一个汉字,前面的一个字节(他称之为高字节)从0xA1用到0xF7,后面一个字节(低字节)从0xA1到0xFE,这样我们就可以组合出大约7000多个简体汉字了。在这些编码里,我们还把数学符号、罗马希腊的字母、日文的假名们都编进去了,连在 ASCII 里本来就有的数字、标点、字母都统统重新编了两个字节长的编码,这就是常说的"全角"字符,而原来在127号以下的那些就叫"半角"字符了。

                中国人民看到这样很不错,于是就把这种汉字方案叫做 "GB2312"。GB2312 是对ASCII 的中文扩展。得意

                但是中国的汉字太多了,我们很快就就发现有许多人的人名没有办法在这里打出来,特别是某些很会麻烦别人的国家领导人。于是我们不得不继续把 GB2312 没有用到的码位找出来老实不客气地用上。得意

               后来还是不够用,于是干脆不再要求低字节一定是127号之后的内码,只要第一个字节是大于127就固定表示这是一个汉字的开始,不管后面跟的是不是扩展字符集里的内容。结果扩展之后的编码方案被称为 GBK 标准,GBK 包括了GB2312 的所有内容,同时又增加了近20000个新的汉字(包括繁体字)和符号。


              后来少数民族也要用电脑了,于是我们再扩展,又加了几千个新的少数民族的字,GBK 扩成了 GB18030。从此之后,中华民族的文化就可以在计算机时代中传承了。

    中国的程序员们看到这一系列汉字编码的标准是好的,于是通称他们叫做 "DBCS"(Double Byte CharecterSet 双字节字符集)。在DBCS系列标准里,最大的特点是两字节长的汉字字符和一字节长的英文字符并存于同一套编码方案里,因此他们写的程序为了支持中文处理,必须要注意字串里的每一个字节的值,如果这个值是大于127的,那么就认为一个双字节字符集里的字符出现了。那时候凡是受过加持,会编程的计算机僧侣们都要每天念下面这个咒语数百遍:

       "一个汉字算两个英文字符!一个汉字算两个英文字符……"惊恐

              因为当时各个国家都像中国这样搞出一套自己的编码标准,结果互相之间谁也不懂谁的编码,谁也不支持别人的编码,连大陆和台湾这样只相隔了150海里,使用着同一种语言的兄弟地区,也分别采用了不同的DBCS 编码方案——当时的中国人想让电脑显示汉字,就必须装上一个"汉字系统",专门用来处理汉字的显示、输入的问题,但是那个台湾的愚昧封建人士写的算命程序就必须加装另一套支持 BIG5 编码的什么"倚天汉字系统"才可以用,装错了字符系统,显示就会乱了套!这怎么办?而且世界民族之林中还有那些一时用不上电脑的穷苦人民,他们的文字又怎么办?

      真是计算机的巴比伦塔命题啊!尴尬

                正在这时,大天使加百列及时出现了——一个叫 ISO (国际标谁化组织)的国际组织决定着手解决这个问题。他们采用的方法很简单:废了所有的地区性编码方案,重新搞一个包括了地球上所有文化、所有字母和符号的编码!他们打算叫它"Universal Multiple-Octet Coded CharacterSet",简称 UCS, 俗称 "UNICODE"。

               UNICODE 开始制订时,计算机的存储器容量极大地发展了,空间再也不成为问题了。于是 ISO 就直接规定必须用两个字节,也就是16位来统一表示所有的字符,对于ascii里的那些“半角”字符,UNICODE包持其原编码不变,只是将其长度由原来的8位扩展为16位,而其他文化和语言的字符则全部重新统一编码。由于"半角"英文符号只需要用到低8位,所以其高8位永远是0,因此这种大气的方案在保存英文文本时会多浪费一倍的空间。

              这时候,从旧社会里走过来的程序员开始发现一个奇怪的现象:他们的strlen函数靠不住了,一个汉字不再是相当于两个字符了,而是一个!是的,从 UNICODE 开始,无论是半角的英文字母,还是全角的汉字,它们都是统一的"一个字符"!同时,也都是统一的"两个字节",请注意"字符"和"字节"两个术语的不同,“字节”是一个8位的物理存贮单元,而“字符”则是一个文化相关的符号。在UNICODE 中,一个字符就是两个字节。一个汉字算两个英文字符的时代已经快过去了。偷笑

            从前多种字符集存在时,那些做多语言软件的公司遇上过很大麻烦,他们为了在不同的国家销售同一套软件,就不得不在区域化软件时也加持那个双字节字符集咒语,不仅要处处小心不要搞错,还要把软件中的文字在不同的字符集中转来转去。UNICODE 对于他们来说是一个很好的一揽子解决方案,于是从Windows NT 开始,MS 趁机把它们的操作系统改了一遍,把所有的核心代码都改成了用UNICODE 方式工作的版本,从这时开始,WINDOWS 系统终于无需要加装各种本土语言系统,就可以显示全世界上所有文化的字符了。

           但是,UNICODE 在制订时没有考虑与任何一种现有的编码方案保持兼容,这使得 GBK 与UNICODE 在汉字的内码编排上完全是不一样的,没有一种简单的算术方法可以把文本内容从UNICODE编码和另一种编码进行转换,这种转换必须通过查表来进行。

           如前所述,UNICODE 是用两个字节来表示为一个字符,这就总共可以组合出65535不同的字符,这大概已经可以覆盖世界上所有文化的符号。如果还不够也没有关系,ISO已经准备了UCS-4方案,说简单了就是四个字节来表示一个字符,这样我们就可以组合出21亿个不同的字符出来(最高位有其他用途),这大概可以用到银河联邦成立那一天吧!

          UNICODE 来到时,一起到来的还有计算机网络的兴起,UNICODE如何在网络上传输也是一个必须考虑的问题,于是面向传输的众多 UTF(UCS Transfer Format)标准出现了,顾名思义,UTF8就是每次8个位传输数据,而UTF16就是每次16个位,只不过为了传输时的可靠性,从UNICODE到UTF时并不是直接的对应,而是要过一些算法和规则来转换。

          从网上引来一段从UNICODE到UTF8的转换规则:抓狂

    Unicode

    UTF-8

    0000 - 007F

    0xxxxxxx

    0080 - 07FF

    110xxxxx 10xxxxxx

    0800 - FFFF

    1110xxxx 10xxxxxx 10xxxxxx

           例如"汉"字的Unicode编码是6C49。6C49在0800-FFFF之间,所以要用3字节模板:1110xxxx 10xxxxxx 10xxxxxx。将6C49写成二进制是:0110 1100 0100 1001,将这个比特流按三字节模板的分段方法分为0110 110001 001001,依次代替模板中的x,得到:1110-011010-110001 10-001001,即E6 B1 89,这就是其UTF8的编码。 

     讲到这里,我们再顺便说说一个很著名的奇怪现象:当你在windows 的记事本里新建一个文件,输入"联通"两个字之后,保存,关闭,然后再次打开,你会发现这两个字已经消失了,代之的是几个乱码!呵呵,有人说这就是联通之所以拼不过移动的原因。

     其实这是因为GB2312编码与UTF8编码产生了编码冲撞的原因。

           而当你新建一个文本文件时,记事本的编码默认是ANSI,如果你在ANSI的编码输入汉字,那么他实际就是GB系列的编码方式,在这种编码下,"联通"的内码是:可怜

        c11100 0001

        aa1010 1010

        cd1100 1101

        a81010 1000

        注意到了吗?第一二个字节、第三四个字节的起始部分的都是"110"和"10",正好与UTF8规则里的两字节模板是一致的,于是再次打开记事本时,记事本就误认为这是一个UTF8编码的文件,让我们把第一个字节的110和第二个字节的10去掉,我们就得到了"00001 101010",再把各位对齐,补上前导的0,就得到了"0000 0000 0110 1010",不好意思,这是UNICODE的006A,也就是小写的字母"j",而之后的两字节用UTF8解码之后是0368,这个字符什么也不是。这就是只有"联通"两个字的文件没有办法在记事本里正常显示的原因。 

         而如果你在"联通"之后多输入几个字,其他的字的编码不见得又恰好是110和10开始的字节,这样再次打开时,记事本就不会坚持这是一个utf8编码的文件,而会用ANSI的方式解读之,这时乱码又不出现了。

         受到过网络编程加持的计算机僧侣们都知道,在网络里传递信息时有一个很重要的问题,就是对于数据高低位的解读方式,一些计算机是采用低位先发送的方法,例如我们PC机采用的 INTEL 架构,这就叫little endian, 而另一些是采用高位先发送的方式, 这就叫big endian. 在网络中交换数据时,为了核对双方对于高低位的认识是否是一致的,采用了一种很简便的方法,就是在文本流的开始时向对方发送一个标志符——如果之后的文本是高位在位,那就发送"FEFF",反之,则发送"FFFE"。不信你可以用二进制方式打开一个UTF-X格式的文件,看看开头两个字节是不是这两个字节?奋斗

      顺便提一下little endian和big endian这两个网络术语的来历: 在<<格列佛游记>>中, 小人国中由于争论吃鸡蛋应该从大头敲还是从小头敲而分成了不同派系, 还发生了战争, 连皇帝都被干掉了. 在计算机技术发展中, 不同体系的硬件之间的通信也因为大头在前还是小头在前产生了同样严重的问题, 因此技术专家里比较幽默的那部分人----那一绝大部分人----就采用了"endian"这个有强烈政治隐喻的术语.

            好了,终于可以回答NICO的问题了,在数据库里,有n前缀的字串类型就是UNICODE类型,这种类型中,固定用两个字节来表示一个字符,无论这个字符是汉字还是英文字母,或是别的什么。

        下面的例子应该可以说明unicode型和ansi型的字段的区别:

        我们在任意类型的数据库中建一个表, 含有如下的字段.

      • nc nchar(10)
      • c char(10)

       然后, 我们再试着向其中加入下面的记录:

      • "1234567890", "1234567890"
      • "一二三四五六七八九十","一二三四五六七八九十"

        对于第一条记录, 两个字段都可以插入10个字符, 同时也都一个字符也多存不了. 

        但对于第二条记录,   nc字段可以把从"一"到"十"的数据都保存进去, 而c字段只能保存到"五",再多就会出错.

        为什么? 因为在nchar字段里, 一个汉字一个字符, 10字符宽的字段就可以保存10个汉字. 而char字段里, 一个汉字算两个字符, 10字符宽的字段就只能保存5个汉字了.

           希望这篇文章对NICO有所帮助.害羞

    展开全文
  • Unity5Network使用方法比之前简单了很多。下面从最基础操作讲解。案例目的:实现两个客户端人在同一个场景中走动互相可以看到。...如下图:步骤2 给Network添加组件 Network Manager netwo

    ntext和text一样用来保存大量的文字数据,不过text用单字节保存数据 ,ntext固定用双字节保存数据. ntext保存的是Uncode的字符 , ntext支持跨语言平台。

     

    ntext:

     

    可变长度 Unicode 数据的最大长度为 230 - 1 (1,073,741,823) 个字符。存储大小是所输入字符个数的两倍(以字节为单位)。ntext 在 SQL-92 中的同义词是 national text。 

     

    ntext中存数据是按双字节存的 ,显示不了NTEXT你换一下recordset打开方式就行了 

     

    text: 

    服务器代码页中的可变长度非 Unicode 数据的最大长度为 231-1 (2,147,483,647) 个字符。当服务器代码页使用双字节字符时,存储量仍是 2,147,483,647 字节。存储大小可能小于 2,147,483,647 字节(取决于字符串)。 

    char、varchar、text和nchar、nvarchar、ntext的区别

    1、CHAR。CHAR存储定长数据很方便,CHAR字段上的索引效率级高,比如定义char(10),那么不论你存储的数据是否达到了10个字节,都要占去10个字节的空间,不足的自动用空格填充。

     

    2、VARCHAR。存储变长数据,但存储效率没有CHAR高。如果一个字段可能的值是不固定长度的,我们只知道它不可能超过10个字符,把它定义为 VARCHAR(10)是最合算的。VARCHAR类型的实际长度是它的值的实际长度+1。为什么“+1”呢?这一个字节用于保存实际使用了多大的长度。从空间上考虑,用varchar合适;从效率上考虑,用char合适,关键是根据实际情况找到权衡点。 

     

    3、TEXT。text存储可变长度的非Unicode数据,最大长度为2^31-1(2,147,483,647)个字符。

     

    4、NCHAR、NVARCHAR、NTEXT。这三种从名字上看比前面三种多了个“N”。它表示存储的是Unicode数据类型的字符。我们知道字符中,英文字符只需要一个字节存储就足够了,但汉字众多,需要两个字节存储,英文与汉字同时存在时容易造成混乱,Unicode字符集就是为了解决字符集这种不兼容的问题而产生的,它所有的字符都用两个字节表示,即英文字符也是用两个字节表示。nchar、nvarchar的长度是在1到4000之间。和char、varchar比较起来,nchar、nvarchar则最多存储4000个字符,不论是英文还是汉字;而char、varchar最多能存储8000个英文,4000个汉字。可以看出使用nchar、nvarchar数据类型时不用担心输入的字符是英文还是汉字,较为方便,但在存储英文时数量上有些损失。

     

     

    对于什么时候用varchar和nvarchar没有说一定的.

    也就是说一个汉字既可以存在varchar中,也可以存在nvarchar中.

    那么对于汉字或者Unicode 数据到底存在varchar和nvarchar有什么区别呢?

    下面例子说明一下:一个汉字占varchar(2),只占nvarchar(1),而字母只占varchar(1),那么在数据库字段求长度的时候,用varchar你就不一定知道它确切的知道它到底有几个字,如果用nvarchar,那么汉字也是nvarchar(1),字母也是nvarchar(1),那么已经很明显了.

    区别2:varchar的检索快于nvarchar,虽然是这样但微软下一个版本将统一nvarchar,听说的

    管理 ntext、text 和 image 数据

    Microsoft? SQL Server? 的 ntext、text 和 image 数据类型在单个值中可以包含非常大的数据量(最大可

       达 2 GB)。单个数据值通常比应用程序在一个步骤中能够检索的大;某些值可能还会大于客户端的可用虚拟内存。因此,

       在检索这些值时,通常需要一些特殊的步骤。

       

       如果 ntext、text 和 image 数据值不超过 Unicode 串、字符串或二进制串的长度(分别为 4,000 个字符、8,000 个字

       符和 8,000 个字节),就可以在 SELECT、UPDATE 和 INSERT 语句中引用它们,其引用方式与较小的数据类型相同。例

       如,包含短值的 ntext 列可以在 SELECT 语句的选择列表中引用,这与 nvarchar 列的引用方式相同。引用时必须遵守一

       些限制,例如不能在 WHERE 子句中直接引用 ntext、text 或 image 列。这些列可以作为返回其它数据类型(例如 

       ISNULL、SUBSTRING 或 PATINDEX)的某个函数的参数包含在 WHERE 子句中,也可以包含在 IS NULL、IS NOT NULL 或 

       LIKE 表达式中。

       

       处理较大的数据值

       但是,如果 ntext、text 和 image 数据值较大,则必须逐块处理。Transact-SQL 和数据库 API 均包含使应用程序可以

       逐块处理 ntext、text 和 image 数据的函数。

       

       数据库 API 按照一种通用的模式处理长 ntext、text 和 image 列: 

       

       若要读取一个长列,应用程序只需在选择列表中包含 ntext、text 或 image 列,并将该列绑定到一个程序变量,该变量

       应足以容纳适当的数据块。然后,应用程序就可以执行该语句,并使用 API 函数或方法将数据逐块检索到绑定的变量中。

       

       

       若要写入一个长列,应用程序可使用参数标记 (?) 在相应位置代替 ntext、text 或 image 列中的值,以执行 INSERT 

       或 UPDATE 语句。参数标记(对 ADO 而言则为参数)被绑定到一个足以容纳数据块的程序变量上。应用程序进入循环,在

       循环中先将下一组数据移到绑定的变量中,然后调用 API 函数或方法写入数据块。这一过程将反复进行,直到整个数据值

       发送完毕。 

       使用 text in row

       在 Microsoft SQL Server 2000 中,用户可以在表上启用 text in row 选项,以使该表能够在其数据行中存储 text、

       ntext 或 image 数据。

       

       若要启用该选项,请执行 sp_tableoption 存储过程,将 text in row 指定为选项名并将 on 指定为选项值。BLOB(二进

       制大对象:text、ntext 或 image 数据)行中可以存储的默认最大大小为 256 字节,但是值的范围可以从 24 到 7000。

       若要指定默认值以外的最大大小,请指定该范围内的整数作为选项值。

       

       如果应用下列条件,则将 text、ntext 或 image 字符串存储在数据行中: 

       

       启用 text in row。

       

       

       字符串的长度比 @OptionValue 所指定的限制短

       

       

       数据行中有足够的可用空间。 

       当 BLOB 字符串存储在数据行中时,读取和写入 text、ntext 或 image 字符串可以与读取或写入字符串和二进制字符串

       一样快。SQL Server 不必访问单独的页以读取或写入 BLOB 字符串。 

       

       如果 text、ntext 或 image 字符串比行中所指定的限制或可用空间大,则将指针存储在该行中。在行中存储 BLOB 字符

       串的条件仍然适用,但是:数据行中必须有足够的空间容纳指针。 

       

       有关更多信息,请参见 sp_tableoption。

       

       使用文本指针

       如果未指定 text in row 选项,text、ntext 或 image 字符串将存储在数据行外;只有这些字符串的文本指针驻留在数

       据行中。文本指针指向由内部指针生成的树的根节点,而这些内部指针映射到实际存储(text、ntext 或 image 数据的)

       字符串段的页。 

       

       SQL Server 2000 中的行文本指针与 SQL Server 早期版本中的文本指针不同。行文本指针的行为就象 BLOB 数据的文件

       句柄;早期的文本指针功能则象 BLOB 数据的地址。因此,在使用行文本指针时,请记住下列特性:

       

       

       

       重要 虽然游标中允许有行文本,但却不允许有行文本指针。如果尝试声明包含行文本指针的游标,SQL Server 将返回错

       误信息(8654、16、1、"A cursor plan could not be generated for the given statement because it contains 

       textptr(inrow lob)."、1033)。

       

       数字 

       对于每个数据库,每个事务最多允许 1024 个活动行文本指针。

       

       锁定 

       当用户获取活动文本指针时,SQL Server 2000 在第一个用户控制文本指针时锁定数据行,并确保没有其他用户修改或删

       除该行。锁在文本指针变为无效时被释放。若要使文本指针无效,请使用 sp_invalidate_textptr。

       

       当事务的隔离级别是未提交读或者数据库为"只读"模式时,文本指针不能用于更新 BLOB 值。

       

       当数据库为"单用户"模式时,SQL Server 2000 不锁定数据行。

       

       为举例说明,给出下面的表:

       

       CREATE TABLE t1 (c1 int, c2 text)

       EXEC sp_tableoption 't1', 'text in row', 'on'

       INSERT t1 VALUES ('1', 'a')

       

       下面的事务将会成功:

       

       INSERT t1 VALUES ('1','This is text.')

       SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

       GO

       BEGIN TRAN

       DECLARE @ptr varbinary(16)

       SELECT @ptr = textptr(c2)

       FROM t1

       WHERE c1 = 1

       READTEXT t1.c2 @ptr 0 5

       COMMIT TRAN

       GO

       

       下面的事务将会失败:

       

       SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

       GO

       BEGIN TRAN

       DECLARE @ptr varbinary(16)

       SELECT @ptr = textptr(c2)

       FROM t1

       WHERE c1 = 1

       WRITETEXT t1.c2 @ptr 'xx'

       COMMIT TRAN

       GO

       

       持续时间 

       行文本指针仅在事务内有效。提交事务时,文本指针变为无效。

       

       在某个事务内,当发生下列任一操作时,行文本指针可能无效:

       

       会话结束。

       

       

       删除该事务中的数据行。(其它事务无法删除数据行,因为该行包含锁。)

       

       

       文本指针所在的表的架构已更改。使文本指针无效的架构更改操作包括:创建或除去聚集索引,改变或除去表,截断表,

       通过 sp_tableoption 更改 text in row 选项,以及执行 sp_indexoption。 

       使用前面的示例,下列脚本在 SQL Server 早期版本中有效,但在 SQL Server 2000 中将生成错误。

       

       DECLARE @ptrval varbinary(16)

       PRINT 'get error here'

       SELECT @ptrval = TEXTPTR(c2)

       FROM t1

       WHERE c1 = 1

       READTEXT t1.c2 @ptrval 0 1

       

       在 SQL Server 2000 中,必须在事务内使用行文本指针:

       

       BEGIN TRAN

       DECLARE @ptrval varbinary(16)

       SELECT @ptrval = TEXTPTR(c2)

       FROM t1

       WHERE c1 = 1

       READTEXT t1.c2 @ptrval 0 1

       COMMIT

       

       NULL 文本 

       可以在由 INSERT 生成的 NULL 文本上获得行文本指针。而在以前,只有将 BLOB 更新为 NULL 后才能获得文本指针。

       

       例如,下列代码在 SQL Server 7.0 中无效,但在 SQL Server 2000 中有效。

       

       SET TRANSACTION ISOLATION LEVEL READ COMMITTED

       GO

       INSERT INTO t1 VALUES (4, NULL)

       BEGIN TRAN

       DECLARE @ptrval VARBINARY(16)

       SELECT @ptrval = TEXTPTR(c2)

       FROM t1

       WHERE c1 = 4

       WRITETEXT t1.c2 @ptrval 'x4'

       COMMIT

       

       在 SQL Server 7.0 中,必须执行下列操作:

       

       INSERT INTO t1 VALUES (4, NULL)

       UPDATE t1 

       SET c2 = NULL 

       WHERE c1 = 4

       DECLARE @ptrval VARBINARY(16)

       SELECT @ptrval = TEXTPTR(c2)

       FROM t1

       WHERE c1 = 4

       WRITETEXT t1.c2 @ptrval 'x4'

       

       下表汇总差别。

       

       差别 行文本指针 非行文本指针 

       数字 对于每个数据库,每个事务最多允许 1024 个活动行文本指针。 无限制。 

       锁定 将数据行一直 S 锁定到指针变为无效为止。 

       当事务为"未提交读"或数据库为"单用户"或"只读"模式时不获取锁。

       不锁定数据行。 

       持续时间 事务或会话结束、删除行或更改表的架构时变为无效。 删除行时变为无效。 

       NULL 文本 插入 NULL 文本后可立即获取。 只有更新后才能获取。 

       

       

       通过数据库 API 使用 ntext、text 和 image 数据

       这一部分概述数据库 API 处理 ntext、text 和 image 数据的方式: 

       

       ADO 

       ADO 可以将 ntext、text 或 image 列或参数映射为 Field 或 Parameter 对象。使用 GetChunk 方法逐块检索数据,使

       用 AppendChunk 方法逐块写数据。有关更多信息,请参见管理 Long 数据类型。 

       

       OLE DB 

       OLE DB 使用 ISequentialStream 接口支持 ntext、text 和 image 数据类型。ISequentialStream::Read 方法逐块读取

       长数据,ISequentialStream::Write 方法将长数据逐块写入数据库。有关更多信息,请参见 BLOB 和 OLE 对象。

       

       ODBC 

       ODBC 具有一种称为"执行中的数据"的功能,可用于处理长数据的 ODBC 数据类型:SQL_WLONGVARCHAR (ntext)、

       SQL_LONGVARCHAR (text) 和 SQL_LONGVARBINARY (image)。这些数据类型被绑定到某个程序变量上。这样一来,就可以调

       用 SQLGetData 逐块检索长数据,调用 SQLPutData 逐块发送长数据。有关更多信息,请参见管理 text 和 image 列。 

       

       DB-Library 

       DB-Library 应用程序也是将 ntext、text 和 image 列绑定到程序变量上。DB-Library 函数 dbtxtptr 用于获取指向数

       据库中长列出现位置的指针,dbreadtext 则用来逐块读取长数据。dbwritetext、dbupdatetext 和 dbmoretext 之类的函

       数用于逐块写入长数据。

     

    展开全文
  • 非 Unicode 字符数据,长度固定,效率较varchar高,输入数据必须是一个长度介于 1 8,000 字节之间数值(这是因为n只能取在18000之间,否则报错)。若输入字符小于指定长度时,它会在后面补空值。若你输入...
  • 很多开发者进行数据库设计时候往往并没有太多考虑char, varchar类型,有是根本就没注意,因为存储价格变得越来越便宜了,忘记了最开始一些基本设计理论原则,这点让我想到了现在年轻人,大手一挥一把...
  • 对于程序中string型字段,SQLServer中有char、varchar、nchar、nvarchar四种类型来对应(暂时不考虑textntext),开建立数据库中,对这四种类型往往比较模糊,这里做一下对比。 定长或变长所谓定长就是...
  • char 单字节类型,char(8)能存8个字母或4个汉字,如果只存了一个字母,内存中也占8个字节 nchar 双字节类型,nchar(8)能存8个字母或8个汉字,如果只存了一个字母或汉字,内存中也占了8个(位) (不分字母汉字以个数计算) ...
  • char、varchar、text和nchar、nvarchar、ntext的区别varchar在SQL Server中是采用单字节来存储数据的,nvarchar是使用Unicode来存储数据的.中文字符存储到SQLServer中会保存为两个字节(一般采用Unico编...
  • varchar nvarchar区别: varchar(n) 长度为 n 个字节可变长度且非 Unicode 字符数据。n 必须是一个介于 1 8,000 之间数值。存储大小为输入数据字节实际长度,而不是 n 个字节。 nvarchar(n) 包含 n ...
  • 定长,就是固定长度,char(5)就是储存固定为5个字符储存空间。 例如存储“123”,存储时候是这样“123 ”,就是固定占用5个字符空间,如果不够5位数,用空格补上。 变长,就是实际存储空间是变长。就是...
  • ncharchar,varchar与nvarchar区别

    热门讨论 2016-02-21 17:33:39
    今天建合作用的数据库,发现每个字段默认类型为nchar(10),以前我们经常接触也就是char和varchar,那前面加了n之后会有什么不同呢? char:对英文(ASCII)字符占用1个字节,对一个汉字占用2个字节,CHAR存储...
  • char、varchar、nchar、nvarchar的区别 对于程序中的string型字段,SQLServer中有char、varchar、nchar、nvarchar四种类型来对应(暂时不考虑textntext),开建立数据库中,对这四种类型往往比较模糊...
  • 关于数据库常用char,varchar,nchar,nvarchar的区别的一些记录 首先,理解unicode编码非Unicode编码 1.unicode为统一编码,就是英文汉字全部采用两个字节(更好的支持汉字) 2.非unicode为非统一编码,就是...
  • char和varchar的长度都在1到8000之间,它们的区别在于char是定长字符数据,而varchar是变长字符数据。所谓定长就是长度固定的,当输入的数据长度没有达到指定的长度时将自动以英文空格在其后面填充,使长度达到相应...
  • ncharchar,varchar与nvarchar区别 最近在公司里做项目,遇到一个问题,建的数据库中文字符音标显示为乱码,组里人所有字符都用varchar表示,所以出现上诉问题,当改为Nvarchar后,问题得到解决。...
  • Char:用Char类型存储数据时,每个字符符号占用一个字节存储空间,定义形式为char(n) n取值为1~8000.如不知道n,系统默认值是1。若输入字符串长度小于n,则系统会在后面添加空格来填满设定长度,若输入...
  • 最近在公司里做项目,遇到一个问题,建的数据库里的中文字符音标显示为乱码,组里的人所有字符都用varchar表示,所以出现上诉问题,当改为Nvarchar后,问题得到解决。所以有必要把他们的区别再重新复习一遍。 ...

空空如也

空空如也

1 2 3 4 5 ... 16
收藏数 308
精华内容 123
关键字:

数据库nchar和char的区别