标签: collation

我使用 SQL Server 2008 R2。

我有一个从数据库中检索到的数据缓存，目前获取字符串的方法是通过map.get(). 但是，代码的某些部分直接从数据库查询而不是仅使用缓存，因为这些情况需要一些连接。现在的问题是，collation表上的 导致通过 SQL 比较（使用表整理）的文本比较和使用map.get().

我已经阅读过，java.text.Collator但需要collator.Compare使用 才能正确使用它。有没有办法强制使用固定的Collator.

顺便说一下，这种情况下的排序规则是使用日语字符，其中在 SQL Server 中进行比较时，半角和全角日语是相同的。

我不知道这个问题到底属于哪个网站，所以发布在这里。

我在 RHEL 6.4 上使用 Postgresql 9.2 并观察到以下内容：

select foo \nfrom unnest(\'{\xd0\xb0,\xd3\x99,\xd0\xb1,\xd0\xb2,\xd0\xb3,\xd0\xb4,\xd0\xb5,\xd0\xb6}\'::text[]) as foo \norder by foo collate "kk_KZ.utf8"\n

给出

\xd0\xb0\n\xd3\x99\n\xd0\xb1\n\xd0\xb2\n\xd0\xb3\n\xd0\xb4\n\xd0\xb5\n\xd0\xb6\n

但

select foo \nfrom unnest(\'{\xd0\xb0,\xd3\x99,\xd0\xb1,\xd0\xb2,\xd0\xb3,\xd0\xb4,\xd0\xb5,\xd0\xb6}\'::text[]) as foo \norder by foo collate "en_US.utf8"\n

给出

\xd0\xb0\n\xd0\xb1\n\xd0\xb2\n\xd0\xb3\n\xd0\xb4\n\xd0\xb5\n\xd3\x99 -- misplaced\n\xd0\xb6\n

此外，我发现有默认 Unicode 排序规则元素表 [1]，其中以正确的顺序列出了有问题的字符 (04D9 ; [.199D.0020.0002.04D9] # CYRILLIC SMALL LETTER SCHWA)。

我知道期望“en_US.utf8”语言环境正确处理西里尔字符是愚蠢的，但是在字符通常不属于所使用的语言/语言环境的情况下，Unicode 或任何其他相关标准的正确行为是什么用于整理？

[1] http://www.unicode.org/Public/UCA/latest/allkeys.txt

在 SQL Server 中如何更改仅选定列的排序规则？有没有办法使用 SQL Server Management Studio 做到这一点？

我在谷歌上搜索，但我发现了如何更改数据库的排序规则而不是特定列的说明。

编辑：

所以我发现这个 SQL 来改变列的排序规则：

ALTER TABLE MyTable 
   ALTER COLUMN Column1 [TYPE] COLLATE [NewCollation]

仍然有办法使用 SQL Server Management Studio 做到这一点吗？

我想将数据库列排序规则设置为俄语和芬兰语。我发现有俄语或芬兰语校对，但没有同时校对。

对于俄罗斯符号 ALTER TABLE Teams CHANGE Name CHARACTER SET cp1251 COLLATE cp1251_bin NOT NULL;

对于芬兰符号 ALTER TABLE Teams CHANGE Name CHARACTER SET cp1251 COLLATE latin1_swedish_ci NOT NULL;

是否有可能同时存储 RU/FI 符号？

我搜索了一些意见，只说明他们从latinto转换utf8，请问我是否可以使用latin_swedish_ci？它与英文字符没有区别，所以可以吗？此外，如果我有一个meta-charset的UTF-8在我的web应用程序和我使用的latin_swedish_ci collation，它会影响什么？我想要你对此的意见。

根据 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或进行比较 …

如何按拉脱维亚语字母顺序对 PostgreSQL 中的文本进行排序，以便任何不带重音的字母始终位于带重音的字母之前？

例如这个

select * from (\n    select \'b\xc4\x81\' as name\n    union select \'\xc4\x81a\'\n    union select \'ac\'\n    union select \'\xc4\x80b\'\n    union select \'\xc4\x80\'\n) t\norder by name COLLATE "lv-x-icu"\n

回报\xc4\x80 \xc4\x81a \xc4\x80b ac b\xc4\x81

但预期结果是ac \xc4\x80 \xc4\x81a \xc4\x80b b\xc4\x81

我尝试创建一些自定义排序规则，但没有一个返回预期结果。

使用SQL Server Management Studio,我得到一些不受欢迎的结果(看起来像我的错误..？)

如果我使用(FIELD而不是field为other_table):

SELECT * FROM main_table WHERE field IN (SELECT FIELD FROM other_table)

我从main_table得到了所有结果.

使用正确的案例:

SELECT * FROM main_table WHERE field IN (SELECT field FROM other_table)

我得到了预期结果,其中字段出现在其他字段中.

在它自己的子查询上运行:

SELECT FIELD FROM other_table

我收到无效的列名错误.

当然我应该在第一种情况下得到这个错误？

这与整理有关吗？DB是二进制排序规则.但是,服务器不区分大小写.在我看来,像服务器组件说"这段代码没问题"并且不允许DB说这个字段是错误的名字..？

我有什么选择解决方案？

是否可以通过包含类似字符的标题字段来命令PostgreSQL查询的结果,[](),;但这样做是否忽略这些标点字符并仅按文本字符排序？

我已经阅读了有关更改数据库排序规则或区域设置的文章,但没有找到关于如何在每个列的现有数据库上执行此操作的任何明确说明.这甚至可能吗？

我检查了每个表的排序规则类型,并且它们具有相同的排序规则.

错误:#1271 - 操作'UNION'的非法混合排序

请参阅以下查询:

$query = "(SELECT id, product_name, description, 'tbl_landt' as type FROM                                      tbl_landt WHERE product_name LIKE '%" . 
          $keyword . "%' OR description LIKE '%" . $keyword ."%') 
           UNION
           (SELECT id, name, null, 'tbl_land_cat' as type FROM tbl_land_cat WHERE name LIKE '%" . $keyword . "%') 
           UNION
           (SELECT tbl_sub_cat.id, tbl_sub_cat.name AS cat_name, null, 'tbl_sub_cat' as type FROM tbl_sub_cat WHERE name LIKE '%" . $keyword . "%')
           UNION
           (SELECT id, name, null, 'tbl_exl_cat' as type FROM tbl_exl_cat WHERE …