【你也能从零基础学会网站开发】SQL Server 2000中的数据类型之String字符串类型

🚀 个人主页 极客小俊
✍🏻 作者简介：程序猿、设计师、技术分享
🐋 希望大家多多支持, 我们一起学习和进步！
🏅 欢迎评论 ❤️点赞💬评论 📂收藏 📂加关注

SQL Server 中字符串类型介绍

啊~~~~ 说到这个字符串类型，那么用处可就多了，我们经常会在实际开发中保存各种各样的字符串类型到数据库中!

并且在 SQL Server 2000 中，字符串类型主要分为两大类：固定长度字符串类型和可变长度的字符串类型。
主要是用来存储文本数据，比如: 名称、描述甚至是一整篇html代码结构都有可能存下来!

那么根据需求划分字符串类型主要被分为以下几种:

如下表

那么我们依次来详细介绍一下这些类型和他们之间的区别

什么叫可变长度、什么叫固定长度 ？

在了解字符串类型之前，我们先要明白一个概念，就是在 字符串类型中的可变与固定的意思!
我们可以利用上表中的char和varchar这两种类型来举例说明!

固定长度（Fixed）char类型

当我们说某个字段是固定长度的时候，意味着这个字段在数据库中占用的空间大小是预先确定且不会改变的。

比如char(n)类型, 无论我们实际存储的字符串有多长（前提条件:只要不超过n个字符范围）, 那么数据库都会为这个字段分配n个字符的空间。

如果存储的字符串长度小于n，数据库可能会用空格或其他填充字符，来填充剩余空间，以确保总长度达到n。
当然这些填充的空格在检索数据时通常会被忽略或自动移除!

例如

比如这里我们设置了char长度为600，那么意思就是无论我们实际存储的字符串有多长,只要不超过这个600个字符的长度,那么数据库都会给这个字段分配600个字符的空间, 懂了吧! 🧐🧐🧐

用通俗易懂的话来讲，就像是你有一个固定大小的盒子，无论你要放进去的糖果数量是多少（只要不超过盒子的容量），你都需要整个盒子来装这些糖果, 对吧! 如果糖果太少，你可能会在盒子里放些填充物来填满空间, 这在数据库中就叫固定长度

当然我们的char设置范围在1 ~ 8000 超出这个设置范围是不行的哈!

如图

不会真有人设置一个8000长度，然后存储一个姓名吧! 🥵🥵

可变长度（Variable） varchar类型

相对固定长度而言可变长度意味着字段在数据库中占用的空间大小可以根据实际存储的数据量来动态调整

举个栗子
varchar(n)为例，这里的n指定了字段可以存储的最大字符数，但实际占用的空间将仅包括存储字符串所需的字符加上一个额外的长度字节（在某些数据库系统中可能是两个字节）来记录字符串的实际长度的, 这意味着如果我们存储的字符串很短，那么字段占用的空间也会相应减少!

如图

这里我们设置了varchar长度为600 那么如果我们实际存的数据只有4个字符,那么就不会占600长度，它会自动调整为这4个字符的占用长度!

想象你有一个可以伸缩的袋子，你可以根据放入物品的多少来调整袋子的大, 如果你只放了几颗糖果，袋子就会保持很小, 如果你放了很多糖果，袋子就会变大来适应🤗🤗 怎么样这种可伸缩的字符串类型是不是很不错!

所以固定长度无论实际存储多少数据，都占用固定的空间大小,而可变长度根据实际存储的数据量来动态调整占用的空间大小,这久是它们彼此主要区别!

在我们平常的数据库设计中，选择固定长度还是可变长度的字段类型取决于具体的应用场景和性能要求,
固定长度也不是一无是处, 这种类型可以提供更好的性能, 因为数据库可以更容易地管理和检索固定大小的数据块, 但可能会导致空间浪费, 比如为了确保数据完整性需要确保存储在字段中的每个值都具有相同的长度时，那么char(n) 就是一个好选择, 如果字段经常存储的字符串长度远小于指定的 n，那么使用 char(n) 可能会导致空间浪费!

而可变长度的字段,例如varchar(n)则可以更灵活地利用存储空间，但可能在某些情况下会影响性能,具体我们在后面的项目项目里慢慢在细谈! 😘😘

SQL Server 2000中的非Unicode字符数据和编码问题

首先要清楚的是Unicode 是一个编码标准，旨在为世界上的每一种系统中的每一个字符提供一个唯一的数字标识符!

当然类似于char(n) 类型在没有特别指定为 Unicode 类型的情况下, 通常使用数据库系统或数据库的默认字符集来存储数据，这个字符集可能不支持或不完全支持 Unicode, 从而可能产生乱码的情况,乱码通常是由于字符编码和解码过程中使用了不匹配的字符集所导致的!

所以在在数据库设计中，尽可能使用支持Unicode的字段数据类型, 这些类型可以确保无论存储什么字符，都不会出现乱码问题,如nchar、nvarchar、ntext这些!

当然我们也可以在创建数据库或表的时候指定一个Unicode字符集作为默认字符集
这样,即使使用char(n)或varchar(n)等类型，也可以在一定程度上确保存储的字符不会因字符集不支持而出现乱码的情况, 这些操作你都可以使用数据库管理系统提供的工具去实现,比如企业管理器、Navicat等…

如图

如果是使用SQL创建数据库，并且指定字符集，可以通过collate子句指定排序规, 如下:

CREATE DATABASE 数据吗名称 collate 字符集名

如图

在SQL Server2000中如果我们不指定编码类型(排序规则)，那么默认会是Chinese_PRC_CI_AS的字符集
这种字符集其实也是一种Unicode字符集的部分，Chinese_PRC_指针对大陆简体字Unicode的排序规则,存储中文还行!

SQL Server 2000查询字符集(排序规则)

在SQL Server 2000中，设置和查看数据库及表的编码主要通过排序规则（Collation）来实现，因为SQL Server中的编码格式主要是通过排序规则来定义的, 所以在这里称呼上字符集编码和排序规则你可以看成是一个东西!

这里要注意一下，因为SQL Server 2000的企业管理器界面较为陈旧，并不支持直接查看排序规则，我们可以使用SQL查询来获取, 比如这里我们使用DATABASEPROPERTYEX函数

SELECT DATABASEPROPERTYEX('你的数据库名称', 'Collation') AS DatabaseCollation

如图

关于修改数据库的排序规则

在SQL Server 2000是不直接支持修改现有数据库的默认排序规则的，因为排序规则是数据库级别的属性，并且与数据的数据存储紧密相关, 如果确实需要更改排序规则，通常需要导出数据、删除数据库、以新的排序规则重新创建数据库，然后导入数据, 这样一波操作下来属实是一个复杂且可能耗时的过程

所以我们在设计数据库时应谨慎选择排序规则!

设置字段的编码

在表已经存在的情况下修改表结构时,我们也可以单独修改字段的排序规则

语法如下

ALTER TABLE 表名称 ALTER COLUMN 字段名 字符串数据类型 COLLATE 字符集名称

例如

ALTER TABLE test ALTER COLUMN username varchar(200) COLLATE Chinese_PRC_CI_AS;

当然也可以在创建表的时候，指定字段的字符集编码

CREATE TABLE 表名称(  字段名 字符串数据类型 COLLATE 字符集名称
)

如图

我们也可以通过企业管理器来可视化修改

如图

SQL Server 2000 常见的字符集如下:

简体中文（中国大陆）

Chinese_PRC_CI_AS：简体中文（中国大陆），不区分大小写，区分重音。
Chinese_PRC_Stroke_CI_AS：简体中文（中国大陆），按笔划排序，不区分大小写，区分重音。

英文

Latin1_General_CI_AS：西欧语言通用，不区分大小写，区分重音。
Latin1_General_BIN：西欧语言通用，二进制排序。

其他语言

Japanese_CI_AS：日语，不区分大小写，区分重音。
Korean_Wansung_CI_AS：韩语（万声），不区分大小写，区分重音。

随意修改编码有多可怕? 看看下面的案例就知道了!

如图

这些中文数据在username字段中为Chinese_PRC_CI_AS字符集编码,我们现在把它修改为Japanese_CI_AS字符集试试看

如图

我们在企业管理器再去查看一下,username字段的数据

如图

看到了吧，出现了乱码! 这就是乱码的原因, 所以字符串类型的字段，是最怕随意乱修改字符集编码的, 这会对实际开发造成很大的阻碍!

另外我们还可以在将数据发送到数据库之前，以及在从数据库检索数据之后，在应用程序中处理字符编码。
这包括确保在发送和接收数据时使用了正确的字符编码，以及在需要时进行编码转换!
这里的应用程序，自然就是我们的php、python、java了, 指的就是在使用如php、python、java等编程语言时，对发送到数据库的数据和从数据库检索的数据进行字符编码的处理, 以便于编码的统一, 这我们在其他的语言开发中进行详细讲解，大家留意一下!

总之了解并正确处理字符编码是避免数据库中出现乱码问题的关键, 在选择字段类型、指定字符集以及在应用程序中处理数据时，都需要特别注意这一点, 这也是字符串类型 最容易出问题的地方!

就目前而言,平常存储中文和英文的数据，UTF-8是最常用的编码方式, 这种编码方式不仅支持中英文，还支持世界上几乎所有的字符系统，具有广泛的兼容性和灵活性,UTF-8编码在存储英文字符时非常节省空间,每个英文字符只占用1个字节，在存储中文字符占用3个字节, 现在基本上在设计数据库、网站或应用程序时，都是使用UTF-8编码来存储中文和英文字符串数据!

nchar和nvarchar类型

其实这两个类型和上面基本上一样，不同的就是他们都支持unicode编码类型, nchar和nvarchar长度范围都是1 到 4,000 个字符 , 其他特性跟char和varchar一样!

但是很多人肯定还会疑惑，到底我是选择前面带n的还是不带n的呢?

其实nchar 和 nvarchar 类型相对于 char 和 varchar 类型来说，会占用更多的存储空间! ! 🤐🤐

因为Unicode编码, 如 UTF-16，UFT-8这些通常比其他编码使用更多的字节来表示字符， 所以在存储大量短文本的时候使用char 和 varchar类型可能会更节省空间, 这都看需求和实际应用场景决定了!

text和ntext 文本类型

这两个类型的区别也是跟上面一样，前面带n和不带n就是是否支持unicode编码类型!

text 用于存储可变长度的非Unicode文本数据，最大长度为2^31-1相当于 = 2,147,483,647 个字符
ntext 用于存储可变长度的Unicode文本数据，最大长度为2^30-1 相当于= 1,073,741,823个字符

在我们的字段需要存储非常巨量的字符串内容的时候，我们就会选择它们!

选择字符串数据类型应用场景

当字段中存储的数据长度几乎总是相同时，那么我们采用 char或 nchar类型

例如
存储固定长度的国际化标识符或代码，确保在不同语言环境下的一致性和准确性,存储一些邮政编码，因为有些邮政编码总是5位数字，可以定义为char(5), 存储固定长度的代码或标识符，如国家代码、货币代码、股票代码等

当字段中存储的数据长度变化较大时，使用 varchar或 nvarchar类型

例如
存储用户的名字或地址，这些信息的长度因用户而异, 存储长度不固定的代码或标识符, 但有一个合理的最大长度限制, 存储用户输入的文本信息，如评论、描述等，这些信息可能包含多种语言的字符,也可能随时被修改!

当需要存储大量文本字符串时，使用 text或 ntext类型最合适!