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

У меня есть запрос 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.

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

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

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 .

Помните, что принятый ответ немного неполон. Да, на самом базовом уровне 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: Спаситель или Лжепророк?

CP1 означает «кодовая страница 1» - технически это означает кодовую страницу 1252.

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

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

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

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

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

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

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