Что делает «COLLATE SQL_Latin1_General_CP1_CI_AS»?


134

У меня есть запрос SQL для создания базы данных в SQLServer, как указано ниже:

create database yourdb
on
( name = 'yourdb_dat',
  filename = 'c:\program files\microsoft sql server\mssql.1\mssql\data\yourdbdat.mdf',
  size = 25mb,
  maxsize = 1500mb,
  filegrowth = 10mb )
log on
( name = 'yourdb_log',
  filename = 'c:\program files\microsoft sql server\mssql.1\mssql\data\yourdblog.ldf',
  size = 7mb,
  maxsize = 375mb,
  filegrowth = 10mb )
COLLATE SQL_Latin1_General_CP1_CI_AS;
go

Работает нормально.

В то время как остальная часть SQL очевидна, я совершенно запутался в функциональности COLLATE SQL_Latin1_General_CP1_CI_AS.

Кто-нибудь может мне это объяснить? Кроме того, я хотел бы знать, является ли создание базы данных таким способом наилучшей практикой?

Ответы:


246

Он устанавливает, как сервер базы данных сортирует (сравнивает фрагменты текста). в таком случае:

SQL_Latin1_General_CP1_CI_AS

разбивается на интересные части:

  1. latin1 заставляет сервер обрабатывать строки, используя charset latin 1, в основном ascii
  2. CP1 обозначает кодовую страницу 1252
  3. CI сравнения без учета регистра, поэтому «ABC» будет равно «abc»
  4. AS чувствительный к акценту, поэтому 'ü' не равно 'u'

PS Для более подробной информации обязательно прочитайте ответ @ solomon-rutzky .


11
Какая будет разница между этим и SQL_Latin1_General_CI_AS. В частности, CP1 заставил меня задуматься.
Кад

7
@Kad: Кажется, нет SQL_Latin1_General_CI_AS. Скорее, есть Latin1_General_CI_AS. См SELECT * FROM fn_helpcollations() where name IN ('SQL_Latin1_General_CP1_CI_AS','Latin1_General_CI_AS','SQL_Latin1_General_CI_AS');. Есть тонкие различия в сортировке и сравнении, как между двумя сопоставлениями. Смотрите olcot.co.uk/sql-blogs/… .
Райли Майор

4
@Kad: CP1 обозначает кодовую страницу 1252. Кодовая страница - это справочная таблица для сопоставления шестнадцатеричного значения определенному символу в наборе символов. CP1 - сокращение от CP1252 в субкультуре Microsoft. Windows является единственной платформой, которая использует CP1252 самостоятельно, так как это время ожидания от DOS. Хотя это очень похоже на ISO 8859-1, они не одинаковы. Существуют различия в отображаемых символах, таких как евро и некоторых других, которые не соответствуют ISO 8859-1.
slartibartfast

безупречный ответ @ Крис!
Гаурав

@ Kris Есть ли альтернатива UTF-8 для SQL_Latin1_General_CP1_CI_AS в SQL2019?
Шенки

72

Помните, что принятый ответ немного неполон. Да, на самом базовом уровне Collation обрабатывает сортировку. НО, правила сравнения, определенные выбранным сопоставлением, используются во многих местах вне пользовательских запросов к пользовательским данным.

Если "Что делает COLLATE SQL_Latin1_General_CP1_CI_AS?" означает «Что делает COLLATEпункт CREATE DATABASE?», то:

В этом COLLATE {collation_name}предложении CREATE DATABASEуказывается сопоставление базы данных по умолчанию , а не сервер; Параметры сортировки по умолчанию на уровне базы данных и на уровне сервера контролируют разные вещи.

Управление на уровне сервера (т.е. экземпляра) :

  • База данных уровня Collation для системных баз данных: master, model, msdb, и tempdb.
  • Благодаря контролю уровня сортировки на уровне базы данных tempdb, он является параметром сравнения по умолчанию для строковых столбцов во временных таблицах (глобальных и локальных), но не в переменных таблицы.
  • Благодаря контролю параметров сортировки на уровне БД master, в таком случае они используются для данных уровня сервера , таких как имена баз данных (т. nameЕ. Столбец в sys.databases), имена входа и т. Д.
  • Обработка имен параметров / переменных
  • Обработка имен курсоров
  • Обработка GOTOэтикеток
  • Сортировка по умолчанию, используемая для вновь созданных баз данных, когда COLLATEотсутствует предложение

Элементы управления на уровне базы данных :

  • По умолчанию Collation используется для вновь созданных строковых столбцов ( CHAR, VARCHAR, NCHAR, NVARCHAR, TEXT, и NTEXT- но не использовать TEXTили NTEXT) когда COLLATEпункт отсутствует в определении столбца. Это касается CREATE TABLEи ALTER TABLE ... ADDзаявлений.
  • Сортировка по умолчанию используется для строковых литералов (т.е. 'some text') и строковых переменных (т.е. @StringVariable). Это сопоставление используется только при сравнении строк и переменных с другими строками и переменными. При сравнении строк / переменных со столбцами будет использоваться сопоставление столбца.
  • Сортировка, используемая для метаданных уровня базы данных, таких как имена объектов (т.е. sys.objects), имена столбцов (т.е. sys.columns), имена индексов (т.е. sys.indexes) и т. Д.
  • Параметры сортировки, используемые для объектов уровня базы данных : таблицы, столбцы, индексы и т. Д.

Также:

  • ASCII - это 8-битная кодировка (для обычного использования; технически ASCII - 7-битная с символьными значениями 0–127, а «ASCII Extended» - 8-битная с символьными значениями 0–255). Эта группа одинакова для разных культур.
  • Кодовая страница является «расширенной» частью Extended ASCII и контролирует, какие символы используются для значений 128 - 255. Эта группа варьируется в зависимости от культуры.
  • Latin1это не среднее значение «ASCII» , так как стандарт ASCII охватывает только значения 0 - 127, и все кодовые страницы (которые могут быть представлены в SQL Server, и даже NVARCHAR) отображают те же 128 значений одних и тех же символов.

Если "Что делает COLLATE SQL_Latin1_General_CP1_CI_AS?" означает «Что делает этот конкретный анализ?», то:

  • Поскольку имя начинается с SQL_, это сопоставление SQL Server, а не сопоставление Windows. Они определенно устарели, даже если официально не устарели, и в основном для совместимости до SQL Server 2000. Хотя, к сожалению, SQL_Latin1_General_CP1_CI_ASэто очень часто встречается из-за того, что он устанавливается по умолчанию при установке на ОС с использованием английского языка США в качестве языка. Эти сопоставления следует избегать, если это вообще возможно.

    Окна (те параметры сортировки, имена которых не начиная с SQL_) являются более новыми, более функциональным, имеют последовательную сортировку между VARCHARи NVARCHARдля одних и тех же значений, и обновляется с дополнительными / исправленный сортировки веса и прописных / строчных отображений. Эти параметры сортировки также не имеют потенциальной проблемы производительности, которую имеют параметры сортировки SQL Server: Влияние на индексы при смешивании типов VARCHAR и NVARCHAR .

  • Latin1_General это культура / язык
    • Для NCHAR, NVARCHARи NTEXTданных это определяет лингвистические правила, используемые для сортировки и сравнения.
    • Для CHAR, VARCHARи TEXTданных (столбцы, литералы и переменные) это определяет:
      • лингвистические правила, используемые для сортировки и сравнения.
      • кодовая страница, используемая для кодирования символов. Например, для Latin1_Generalсопоставлений используется кодовая страница 1252, для Hebrewсопоставлений используется кодовая страница 1255 и т. Д.
  • CP{code_page} или {version}

    • Для параметров сортировки SQL Server : CP{code_page}8-разрядная кодовая страница, определяющая, какие символы соответствуют значениям 128 - 255. В то время как для двухбайтовых наборов символов (DBCS) существуют четыре кодовые страницы, которые могут использовать двухбайтовые комбинации для создания более 256 символов, они недоступны для параметров сортировки SQL Server.
    • Для параметров сортировки Windows : {version}хотя и присутствует не во всех именах параметров сортировки, относится к версии SQL Server, в которой было представлено сравнение (по большей части). Параметры сортировки Windows без номера версии в имени являются версией 80(имеется в виду SQL Server 2000, то есть версия 8.0). Не все версии SQL Server поставляются с новыми параметрами сортировки, поэтому в номерах версий есть пробелы. Некоторые из них 90(для SQL Server 2005, версия 9.0), большинство 100(для SQL Server 2008, версия 10.0) и небольшой набор 140(для SQL Server 2017, версия 14.0).

      Я сказал «по большей части», потому что параметры сортировки, заканчивающиеся на, _SCбыли введены в SQL Server 2012 (версия 11.0), но базовые данные не были новыми, они просто добавили поддержку дополнительных символов для встроенных функций. Таким образом, эти окончания существуют для версии 90и параметров 100сортировки, но только начиная с SQL Server 2012.

  • Далее у вас есть чувствительность, которая может быть в любой комбинации из следующих, но всегда указывается в следующем порядке:
    • CS= с учетом регистра или CI= без учета регистра
    • AS= чувствительный к AIакценту или = нечувствительный к акценту
    • KS = Кана чувствительна к типу или отсутствует = кана нечувствительна к типу
    • WS = ширина чувствительна или отсутствует = ширина нечувствительна
    • VSS = чувствительный к селектору вариаций (доступен только в версии 140 параметров сортировки) или отсутствует = нечувствительный к селектору вариаций
  • Необязательный последний кусок:

    • _SCв конце означает «Поддержка дополнительных символов». «Поддержка» влияет только на то, как встроенные функции интерпретируют суррогатные пары (как кодируются дополнительные символы в UTF-16). Без _SCв конце (или _140_в середине) встроенные функции не видят ни одного дополнительного символа, а вместо этого видят две бессмысленные кодовые точки, которые составляют суррогатную пару. Это окончание может быть добавлено к любому небинарному сопоставлению версии 90 или 100.
    • _BINили _BIN2в конце означает «двоичную» сортировку и сравнение. Данные по-прежнему хранятся так же, но языковых правил нет. Это окончание никогда не сочетается ни с одной из 5 чувствительности или _SC. _BINэто старый стиль, и _BIN2это более новый, более точный стиль. Если используется SQL Server 2005 или новее, используйте _BIN2. Для получения подробной информации о различиях между _BINи _BIN2, пожалуйста, смотрите: Различия между различными двоичными сопоставлениями (культуры, версии и BIN против BIN2) .
    • _UTF8это новая опция с SQL Server 2019. Это 8-битная кодировка, которая позволяет хранить данные в Юникоде VARCHARи CHARтипы данных (но не устаревший TEXTтип данных). Этот параметр можно использовать только для сопоставлений, которые поддерживают дополнительные символы (то есть сопоставления версии 90 или 100 с _SCих именем и сопоставления версии 140). Существует также одно двоичное _UTF8сопоставление ( _BIN2не _BIN).

      ПОЖАЛУЙСТА, ОБРАТИТЕ ВНИМАНИЕ: UTF-8 был разработан / создан для совместимости со средами / кодом, которые настроены для 8-битного кодирования, но хотят поддерживать Unicode. Несмотря на то, что есть несколько сценариев, в которых UTF-8 может обеспечить до 50% экономии пространства по сравнению с этим NVARCHAR, это является побочным эффектом и приводит к небольшому снижению производительности во многих / большинстве операций. Если вам это нужно для совместимости, то стоимость приемлема. Если вы хотите это для экономии места, вам лучше пройти тест и снова протестировать. Тестирование включает в себя все функциональные возможности и не только несколько строк данных. Имейте в виду, что параметры сортировки UTF-8 работают лучше всего, когда ВСЕ столбцы и сама база данных используют VARCHARданные (столбцы, переменные, строковые литералы) с_UTF8сверка. Это естественное состояние для всех, кто использует это для совместимости, но не для тех, кто надеется использовать его для экономии места. Будьте осторожны при смешивании данных VARCHAR с использованием параметров _UTF8сортировки либо с использованием VARCHARданных, не связанных с _UTF8сортировкой, либо с NVARCHARданными, поскольку вы можете столкнуться со странным поведением / потерей данных. Дополнительные сведения о новых сопоставлениях UTF-8 см. В разделе: Собственная поддержка UTF-8 в SQL Server 2019: Спаситель или Лжепророк?


5
Хотя я высказал это за то, что содержал так много информации и усилий, Мой ответ определенно не ошибается (базы данных хранят данные, серверы баз данных действуют на эти данные, сортировка действует). Я выбрал краткость, а не математическую точность, потому что ОП, вероятно, искал достаточно, а не всю возможную информацию.
Крис

4
Привет, Крис. Спасибо. Честно говоря, я не говорил, что ваш ответ был совершенно неправильным, просто ужасно неполным. Я обновил, чтобы надеюсь уточнить это. Я понимаю, что вы говорите, но ОП спросил, что делает COLLATEпункт CREATE DATABASE. Вы сказали одну из нескольких вещей, которые он делает. Почему вы предполагаете, что ОП хочет знать только 10% ответа? Если вся информация представлена, каждый человек может решить, сколько ее взять. Но если дана только некоторая информация, то выбор был сделан для них. Я решил предоставить как можно больше информации, потому что большая ее часть не очень известна. (продолжение)
Соломон Руцкий

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

8
@Kris Я уже давно хотел сказать "Спасибо!" за проявление такой зрелости и профессионализма. Я несколько привык к тому, что люди обижаются на кого-то, кто говорит, что они не правы, а затем становится «трудным» (или даже более трудным) для взаимодействия. Но ваш взвешенный ответ на мой «принятый ответ НЕПРАВИЛЬНО » вдохновил меня на то, чтобы смягчить мое вступление и послужить примером для других здесь, как правильно и продуктивно общаться ».
Соломон Руцкий,

4
Добро пожаловать и приятно слышать, что я как-то оказал положительное влияние, но мне нравится быть «неправильным», это открывает возможности для изучения новых вещей, и это здорово!
Крис


16

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

Например, в вашем случае вы используете латинские правила с нечувствительным к регистру ( CI ) и чувствительным к акценту ( AS )

Вы можете обратиться к этой документации


9

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

База данных всегда имеет параметры сортировки по умолчанию. Если вы не укажете их, будет использоваться сопоставление по умолчанию для экземпляра SQL Server.

Название используемой сортировки показывает, что она использует кодовую страницу Latin1 1, нечувствительна к регистру (CI) и акценту (AS). Это сопоставление используется в США, поэтому оно будет содержать правила сортировки, используемые в США.

Сортировка определяет, как текстовые значения сравниваются на равенство и сходство и как они сравниваются при сортировке. Кодовая страница используется при хранении данных, не относящихся к юникоду, например полей varchar.


неправильный (вы не можете notуказать параметры сортировки, хотя вы можете принять значение по умолчанию) неправильный (он также используется для данных Unicode)
RichardTheKiwi

@Richard ака cyberkiwi: Проверьте документацию: msdn.microsoft.com/en-us/library/ms176061.aspx Задание сверка является необязательным. Кодовая страница не используется для хранения данных Unicode, поскольку они хранятся как 16-битные кодовые точки Unicode, а не как 8-битные индексы кодовых страниц.
Guffa

Я прочитал ваш ответ неправильно, но все равно неправильно. База данных всегда имеет параметры сортировки по умолчанию = параметры SERVER , а не конкретно Latin1_General_CI_AS. Теперь я прочитал это неправильно, потому что я наполовину ожидал, что утверждение будет касаться сортировки SERVER, которая требует принятия по умолчанию в пользовательском интерфейсе. Что касается 2-го пункта, вы, похоже, подразумеваете, что сортировка не используется для сортировки данных в Юникоде (даже если вы переключаетесь с sortingна storingв последних 2 предложениях). Текстовые данные Unicode также подчиняются параметрам сортировки.
RichardTheKiwi

@Richard aka cyberkiwi: я изменил абзац о сопоставлении по умолчанию, чтобы соответствовать конкретной документации, на которую я ссылался. (Это зависит от версии сервера.) Что касается второго пункта, я не вижу, как я мог бы сделать это более понятным. В тексте говорится, что кодовая страница используется при хранении данных, не относящихся к юникоду. Кодовая страница не используется для определения сортировки ни для данных Unicode, ни для данных не-Unicode.
Guffa
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.