相关疑难解决方法(0)

我正在我的学校使用一个小型网络应用程序的数据库SQL Server 2005.
我在varcharvs 的问题上看到了几个思想流派nvarchar:

1. 使用varchar除非你处理了很多国际化的数据,然后使用nvarchar.
2. 只是nvarchar用于一切.

我开始看到视图2的优点.我知道nvarchar确实占用了两倍的空间,但这不一定是一个大问题,因为这只是为几百名学生存储数据.对我而言,似乎最简单的是不要担心它并且只允许一切使用nvarchar.还是有什么我想念的？

所有 3 个选项都区分大小写和重音，并支持 Unicode。根据文档：

1. NVarchar 根据“相关语言或字母表的字典”对数据进行排序和比较 (?)

2. Bin 根据“位模式”（？）对数据进行排序和比较

3. Bin2根据“Unicode数据的Unicode代码点”对数据进行排序和比较（？）

把复杂的事情简单化，我能不能说Bin是NVarchar的改进，Bin2是Bin的改进；除非我仅限于向后兼容，否则总是建议使用 Bin2 或至少使用 Bin 以享受更好的性能？

================================================== ======================== 我会再次尝试解释我自己。

看一看：

If Object_ID('words2','U') Is Not Null Drop Table words2;
Create  Table words2(word1 NVarchar(20),
                    word2 NVarchar(20) Collate Cyrillic_General_BIN,
                    word3 NVarchar(20) Collate Cyrillic_General_BIN2);

Insert
Into    words2
Values  (N'???????',N'???????',N'???????'),
        (N'?????????',N'?????????',N'?????????'),
        (N'?????',N'?????',N'?????'),
        (N'???',N'???',N'???');
Select * From words2;

所有 3 个选项都支持各种字母表，无论是什么排序规则。

问题是 - 3 个选项之间的实际区别是什么？假设我想以不同的字母存储私人姓名，我可以使用哪个选项？我想我将不得不找到特定的名称（选择...从...在哪里...），订单名称（选择...从...订购...）。

根据 SQL Server 的文档（和遗留文档），nvarchar没有_SC排序规则的字段应该使用UCS-2 ENCODING.

从 SQL Server 2012 (11.x) 开始，当使用支持补充字符 (SC) 的排序规则时，这些数据类型存储完整范围的 Unicode 字符数据并使用 UTF-16 字符编码。如果指定了非 SC 归类，则这些数据类型仅存储 UCS-2 字符编码支持的字符数据子集。

它还指出，UCS-2 ENCODING仅存储 支持的子集字符UCS-2。从维基百科UCS-2 规范：

UCS-2 对每个字符使用 0 到 65,535 之间的单个代码值 [...]，并且只允许两个字节（一个 16 位字）来表示该值。因此，UCS-2 允许 BMP 中表示字符的每个代码点的二进制表示。UCS-2 不能表示 BMP 之外的代码点。

因此，根据上面的规范，我似乎无法存储像这样的表情符号：其值为0x1F60D（或十进制的 128525，远高于 UCS-2 的 65535 限制）。但是在 SQL Server 2008 R2 或 SQL Server 2019（都带有 default SQL_Latin1_General_CP1_CI_AS COLLATION）上，在一个nvarchar字段上，它被完美地存储和返回（尽管不支持与LIKE或进行比较 …