Какво прави „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“

P.S. За по-подробна информация не забравяйте да прочетете отговора на @solomon-rutzky.

Моля, имайте предвид, че приетият отговор е малко непълен. Да, на най-базовото ниво Collation обработва сортирането. НО правилата за сравнение, определени от избраното съпоставяне, се използват на много места извън потребителските заявки срещу потребителски данни.

Ако "Какво прави COLLATE SQL_Latin1_General_CP1_CI_AS?" означава "Какво прави клаузата COLLATE на CREATE DATABASE?", тогава:

Клаузата COLLATE {collation_name} на израза CREATE DATABASE определя съпоставянето по подразбиране на Базата данни, а не сървъра; Сравняванията по подразбиране на ниво база данни и на ниво сървър контролират различни неща.

Контроли на ниво сървър (т.е. екземпляр):

• Съпоставяне на ниво база данни за системни бази данни: master, model, msdb и tempdb.
• Поради контролирането на съпоставянето на ниво DB на tempdb, тогава това е съпоставянето по подразбиране за низови колони във временни таблици (глобални и локални), но не и променливи на таблици.
• Поради контролирането на съпоставянето на ниво DB на master, това е съпоставянето, използвано за данни на ниво сървър, като например имена на бази данни (т.е. name колона в sys.databases), имена за вход и т.н.
• Обработка на имена на параметри / променливи
• Обработка на имена на курсори
• Обработка на GOTO етикети
• Подреждане по подразбиране, използвано за новосъздадени бази данни, когато клаузата COLLATE липсва

Контроли на ниво база данни:

• Подреждане по подразбиране, използвано за новосъздадени низови колони (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 е много често срещан, тъй като е по подразбиране при инсталиране на операционна система, използваща американски английски като език. Тези сравнявания трябва да се избягват, ако изобщо е възможно.

  Сортирането на Windows (тези с имена не започващи с SQL_) са по-нови, по-функционални, имат последователно сортиране между VARCHAR и NVARCHAR за едни и същи стойности и се актуализират с допълнителни/коригирани тегла на сортиране и главни/малки букви съпоставяния. Тези съпоставки също нямат потенциалния проблем с производителността, който имат съпоставките на SQL Server: Въздействие върху индексите при смесване на типове VARCHAR и NVARCHAR.

• Latin1_General is the culture / locale.
  • For NCHAR, NVARCHAR, and NTEXT data this determines the linguistic rules used for sorting and comparison.
  • For CHAR, VARCHAR, and TEXT data (columns, literals, and variables) this determines the:
    • linguistic rules used for sorting and comparison.
    • кодова страница, използвана за кодиране на знаците. Например Latin1_General съпоставянето използва кодова страница 1252, Hebrew съпоставянето използва кодова страница 1255 и т.н.

• CP{code_page} or {version}

  • For SQL Server collations: CP{code_page}, is the 8-bit code page that determines what characters map to values 128 - 255. While there are four code pages for Double-Byte Character Sets (DBCS) that can use 2-byte combinations to create more than 256 characters, these are not available for the SQL Server collations.

  • За сортиране на 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.

• Next you have the sensitivities, that can be in any combination of the following, but always specified in this order:
  • CS = case-sensitive or CI = case-insensitive
  • AS = чувствителен към акцент или AI = нечувствителен към акцент
  • KS = Kana е чувствителен към типа или липсва = Kana е нечувствителен към типа
  • WS = чувствителен към ширина или липсващ = нечувствителен към ширина
  • VSS = селекторът на варианти е чувствителен (наличен само във версия 140 съпоставки) или липсва = селекторът на вариант е нечувствителен

• Последна част по избор:

  • _SC at the end means "Supplementary Character support". The "support" only affects how the built-in functions interpret surrogate pairs (which are how supplementary characters are encoded in UTF-16). Without _SC at the end (or _140_ in the middle), built-in functions don't see a single supplementary character, but instead see two meaningless code points that make up the surrogate pair. This ending can be added to any non-binary, version 90 or 100 collation.
  • _BIN или _BIN2 в края означава "двоично" сортиране и сравнение. Данните все още се съхраняват същите, но няма лингвистични правила. Този край никога не се комбинира с някоя от 5-те чувствителност или _SC. _BIN е по-старият стил, а _BIN2 е по-новият, по-точен стил. Ако използвате SQL Server 2005 или по-нов, използвайте _BIN2. За подробности относно разликите между _BIN и _BIN2, моля, вижте: Разлики между различните двоични съпоставки (култури, версии и BIN срещу BIN2).

  • _UTF8 е нова опция от SQL Server 2019. Това е 8-битово кодиране, което позволява Unicode данни да се съхраняват в 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

Ключовата дума COLLATE указва какъв вид набор от знаци и правила (ред, правила за конфронтация) използвате за низови стойности.

Например във вашия случай използвате латински правила с нечувствителни към главни и малки букви (CI) и чувствителни към ударения (AS)

Можете да се обърнете към тази документация

Това определя сортирането по подразбиране за базата данни. Всяко текстово поле, което създавате в таблици в базата данни, ще използва това сортиране, освен ако не посочите друго.

Базата данни винаги има сортиране по подразбиране. Ако не посочите нито един, се използва сортирането по подразбиране на екземпляра на SQL Server.

Името на сортирането, което използвате, показва, че то използва латинската1 кодова страница 1, не е чувствително към главни и малки букви (CI) и чувствително към акцент (AS). Това сортиране се използва в САЩ, така че ще съдържа правила за сортиране, които се използват в САЩ.

Подреждането решава как текстовите стойности се сравняват за равенство и подобие и как се сравняват при сортиране. Кодовата страница се използва при съхраняване на не-уникод данни, напр. varchar полета.