Имена сортировки Microsoft SQL Server - PullRequest
Новая
       4

Имена сортировки Microsoft SQL Server

3 голосов
/ 16 февраля 2011

Кто-нибудь знает, что делает свойство WS сортировки? Имеет ли это какое-либо отношение к сценариям азиатского типа? Документы MSDN объясняют его как «чувствительный к ширине», но это не имеет никакого смысла, скажем, на шведском или английском ...?

Ответы [ 2 ]

5 голосов
/ 16 февраля 2011

Хорошее описание чувствительности к ширине суммировано здесь: http://www.databasejournal.com/features/mssql/article.php/3302341/SQL-Server-and-Collation.htm

Чувствительность к ширине

Когда однобайтовый символ (полуширина) и тот же символ, когда он представленпоскольку двухбайтовые символы (полная ширина) обрабатываются иначе, чем они чувствительны к ширине.

Возможно, с точки зрения английского символа, я бы предположил, что чувствительная к ширине сортировка будет означать, что 'abc«<> N'abc», потому что одна строка является строкой Unicode (2 байта на символ), а другая - одним байтом на символ.

С точки зрения латинского набора символов это кажется чем-то, что не имеет смысла устанавливать.Возможно, на других языках это важно.

Я пытаюсь установить эти типы свойств сортировки как нечувствительные в целом, чтобы избежать странных вещей, таких как записи, которые не возвращаются в результатах поиска.Обычно я оставляю акценты нечувствительными, так как это может вызвать много проблем с поиском пользователей, в зависимости от аудитории ваших приложений.

Редактировать: После создания тестовой базы данных с сопоставлением Latin1_General_CS_AS_WS я обнаружил, что N'a '= N'A' на самом деле верно.Тестовыми запросами были: 

select case when 'a' = 'A' then 'yes' else 'no' end
select case when 'a' = 'a' then 'yes' else 'no' end
select case when N'a' = 'a' then 'yes' else 'no' end

Так что на практике я не уверен, где этот тип правил вступает в игру

1 голос
/ 22 февраля 2011

Принятый ответ показывает, что он не входит в игру для сравнения N'a' = 'a'. Это легко объяснить, потому что char будет неявно преобразован в nchar при сравнении между этими двумя значениями, так что обе строки в сравнении имеют Unicode.

Я только что подумал о примере места, где чувствительность к ширине может вступить в игру в латинице, только чтобы обнаружить, что и там, похоже, вообще нет никакой разницы ... 

DECLARE @T TABLE (
  a VARCHAR(2) COLLATE Latin1_General_100_CS_AS_WS,
  b VARCHAR(2) COLLATE Latin1_General_100_CS_AS_WS )

INSERT INTO @T
VALUES      (N'Æ',
             N'AE');

SELECT LEN(a) AS [LEN(a)],
       LEN(b) AS [LEN(b)],
       a,
       b,
       CASE
         WHEN a = b THEN 'Y'
         ELSE 'N'
       END    AS [a=b]
FROM   @T 

LEN(a)      LEN(b)      a    b    a=b
----------- ----------- ---- ---- ----
1           2           Æ    AE   Y

Об этом говорится в книге "Внутренние компоненты Microsoft SQL Server 2008".

Ширина чувствительности относится к Восточной Азии языки, для которых существуют оба полуширина и полуширина формы некоторые символы.

Абсолютно ничто не мешает вам хранить эти символы в сопоставлении, таком как Latin1_General_100_CS_AS_WS, если столбец имеет тип данных Unicode, поэтому я предполагаю, что часть WS будет применяться только в этой конкретной ситуации.

...