TL; DR
Не существует такого понятия, как «независимый от поставщика» вид Collations, и даже не «независимый от версии», поскольку их реализации, включая аспекты, которые можно сделать нечувствительными, и соглашения об именах - зависят от поставщика и изменяются с течением времени. ,
Вот краткое изложение того, что я нашел, и подробности в более длинном разделе под строкой:
RDBMS Naming- Combinations Case-Sensitive and
convention of options? Accent-Insensitive support?
------- ------------ ------------- -----
SQL Server _CS, _AI, etc Yes Latin1_General_100_CS_AI
DB2 _E{x}, _S{y}, etc Yes CLDR181_EO_S1
PostgreSQL locale: en_US N/A unaccent(), not via Collation
MySQL _cs, maybe _ai No No: _cs implies _as & _ci implies _ai
Yes? Create your own Collation :-)
Oracle only _CI & _AI No No: _AI always implies _CI
SAP ASE arbitrary: turdict N/A No: "AI" always implies "CI"
Informix locale.codepage N/A No: no "AI" via Collations
Как вы можете видеть на диаграмме, две из семи РСУБД поддерживают «чувствительный к регистру» операции «с и без акцента» через сопоставления, хотя они имеют разные соглашения об именах (и некоторые другие функциональные различия).
Одна СУБД - PostgreSQL - изначально не поддерживает эту комбинацию, но вы все равно можете достичь ее, удалив акценты с помощью unaccent() надстройки.
Последние четыре СУБД, две из которых имеют схожее соглашение об именах для опций, не поддерживают эту комбинацию изначально, и, как представляется, не существует средства для достижения этой цели без написания собственной функции удаления акцентов / диакритических знаков. MySQL позволяет создавать свои собственные параметры сортировки, но для этого требуется, чтобы вы затем добавили его в систему управления версиями и включили его в процесс тестирования и развертывания, чтобы его можно было применить ко всем серверам во всех средах (но все же это очень крутой и гибкий вариант) , SAP ASE упоминает, что SAP может предоставлять дополнительные заказы на сортировку в Юникоде, но не упоминается о том, что они могут быть готовы предоставить.
Что касается:
Есть ли для этого веская причина или у меня просто редкий случай использования?
Я могу сказать, что, проводя исследование этого ответа, я сталкивался с множеством людей, которые хотели бы видеть MySQL без учета регистра и с ударением на MySQL, но лишь немногие, если таковые вообще возникали, спрашивали о желаемой комбинации.
Я хотел, чтобы условие поиска использовало регистр с учетом регистра, но без учета акцента, но не смог найти его.
...
этот вопрос не зависит от поставщика / версии
Вы потерпели неудачу в поиске, потому что на самом деле не имеет смысла искать СУБД на основе спецификации сопоставления. Это просто не так, как работает Collation. И хотя вы хотите подходить к этому как к независимому от поставщика, реальность такова, что сопоставления - по крайней мере та часть, с которой мы взаимодействуем - очень сильно зависят от поставщика и не всегда вписываются в схему, по которой вы искали ,
Сравнение и сортировка строк очень сложны, и существуют разные способы выполнения этих правил. Одним из методов является отображение, которое учитывает одно или несколько правил. Следовательно, четыре комбинации «Чувствительный» и «Нечувствительный» для падежа и ударения равняются четырем отдельным сопоставлениям. Например, вы видели это на этой странице MSDN для имени сортировки SQL Server . Если вы прокрутите вниз, вы увидите, что левый столбец диаграммы - это Sort Order ID. У каждого сопоставления свой идентификатор: SQL_Latin1_General_Cp1_CI_AS= 52, аSQL_Latin1_General_Cp1_CS_AS = 51, хотя единственная разница заключается в чувствительности к регистру.
Или это может быть основано на правилах, например, то, что предлагает Unicode через алгоритм сортировки Unicode (UCA). При таком подходе каждому символу по умолчанию присваивается один или несколько весов. Затем каждая культура / локаль имеет возможность переопределить любой из этих весов, или удалить правила, или добавить правила. Алгоритм учитывает любые специфичные для локали правила, а затем потенциально манипулирует этими весами на основе любых выбранных опций (чувствительность, какой случай стоит первым при выполнении сортировки с учетом регистра и т. Д.). Это одна из причин, почему сортировка по Юникоду немного медленнее, чем не по Юникоду.
Чтобы понять, сколько на самом деле вариантов (то есть реальной сложности), посмотрите эту демонстрацию из проекта ICU (International Components for Unicode):
ICU Collation Demo
Есть 8 отдельных параметров , чтобы указать, и некоторые из них получают представлены в нескольких элементов спецификации Collation имя , что вы думаете (например CS, CI, AS, AIи т.д.). Учитывая, сколько существует вариантов, использование подхода с использованием файла сопоставления, в котором каждая комбинация имеет свой собственный идентификатор, приведет к созданию многих тысяч файлов. Многие из этих файлов необходимо будет обновлять всякий раз, когда происходят изменения в этих конкретных языках или когда обнаруживаются ошибки. Вероятно, поэтому в SQL Server 2012 существует только 75 таких типов сопоставлений (то есть с именами, начинающимися с SQL_). Следовательно, нет комбинации для _CS_AI.
И причина, почему вы не смогли найти эту комбинацию для сопоставлений на основе УЦА? Ну, в SQL Server 2012 есть 3810 параметров сортировки, которые не начинаются сSQL_ , поэтому всего 3885 параметров сортировки. Этот список кажется слишком длинным, чтобы его можно было полностью перечислить на веб-странице. Но это не полностью объясняет, почему вы не можете найти эту комбинацию для других поставщиков.
Помимо того, что уже было упомянуто (т. Е. Слишком много комбинаций для реализации и слишком много реализаций для перечисления), вам все равно придется бороться с реализациями, специфичными для поставщика. Значение: не все поставщики допускают адаптацию всех этих опций, и в первую очередь не существует стандартного соглашения о присвоении имен для сопоставлений. Кроме того, не все поставщики рассматривают параметры сортировки как часть сортировки: сортировки PostgreSQL являются порядком по умолчанию для выбранной локали, и вам необходимо использовать их ILIKEдля сравнения без учета регистра. См. Ниже информацию для конкретного поставщика.
SQL Server (Microsoft)
Различие между тем, что вы видите на этих двух страницах документации MSDN, и запросом, предоставленным @MartinSmith в комментарии к вопросу (слегка пересмотренный ниже):
SELECT *
FROM sys.fn_helpcollations()
WHERE [name] LIKE '%[_]CS[_]AI%';
заключается в том, что эти две страницы MSDN специально ссылаются на очень устаревшие параметры сортировки SQL Server, тогда как параметры сортировки, которые отображаются в результате этого запроса (888 из них по состоянию на SQL Server 2012 с пакетом обновления 3), представляют собой параметры сортировки Windows.
Начиная с SQL Server 2000, более старые параметры сортировки SQL Server (созданные до того, как SQL Server мог подключаться к параметрам сортировки Windows) устарели и не обновляются новыми правилами или функциями. Например, начиная с SQL Server 2012, был добавлен набор параметров сортировки, которые поддерживают правильную обработку встроенных функций для дополнительных символов (т. Е. Оставшихся символов UTF-16 за пределами «базовых» 65 536 символов, первоначально определенных в UCS-2). ). Эти новые параметры сортировки заканчиваются _SC(как в S upplementary C Символов).
Лучше не использовать сопоставления SQL Server - те, чьи имена начинаются с SQL_. Следовательно, у вас есть доступ ко множеству параметров сортировки, которые поддерживают комбинацию искомых параметров (например, с учетом регистра и с учетом акцента). Когда это возможно, лучше использовать один конец, _SCесли у него есть все остальные опции, которые вы хотите.
Хотя SQL Server действительно использует _CS_AIсоглашение об именах, нет списка всех 3810 (по состоянию на SQL Server 2012) параметров сортировки Windows. Существует только страница имени сортировки Windows, в которой перечислены все локали и версии, а также принципы работы соглашения об именах, но это все.
SQL Server также поддерживает переключение чувствительности ширины и кана.
MySQL (покупается Oracle)
MySQL версии 5.7, документации говорится , что она поддерживает _ai, _as, _ci, и _csсуффиксы (и _binдля полноты), но и утверждает:
Для недвоичных имен сопоставления, которые не определяют чувствительность к акценту, это определяется чувствительностью к регистру. То есть, если имя сопоставления не содержит _aiили _as, _ciв названии подразумевается _aiи _csв названии подразумевается _as.
Например, latin1_general_ciнечувствителен к регистру (и не чувствителен к акценту, неявно), latin1_general_csчувствителен к регистру (и неявно чувствителен к акценту)
Это, безусловно, подразумевает, что возможно иметь latin1_general_cs_aiсопоставление. Тем не менее, сервер MySQL 5.5.50 , что у меня есть доступ к не имеет сопоставления с более чем одним суффиксом, и только суффиксы я вижу , являются: _cs, _ciи _binчерез 198 полных Collations. Я использовал команду SHOW COLLATION, чтобы перечислить их.
Поэтому, хотя звучит так, как будто MySQL использует аналогичное соглашение об именах (по крайней мере, в отношении этих двух вариантов), я не могу найти сопоставление, соответствующее тому, что вы ищете. Тем не менее, может быть возможно снять акценты (и другие диакритические знаки) и использовать _csсопоставление, чтобы получить то, что вы хотите (аналогично тому, как вы это сделали бы в PostgreSQL - см. Ниже). Но я не уверен в этом варианте и у меня нет времени на дальнейшие исследования.
ИЛИ , вы можете создать свой собственный Collation, чтобы делать именно то, что вы хотите. В отличие от других РСУБД, MySQL, по-видимому, делает довольно простым добавление ваших собственных сопоставлений, и в этом случае вы полностью контролируете вес каждого символа. См. Добавление простого сопоставления в 8-битный набор символов и Добавление сопоставления UCA в набор символов Unicode для получения более подробной информации.
Для получения дополнительной информации о том, как MySQL обрабатывает различные типы сортировок, см. Их страницу Типы реализации сопоставления .
PostgreSQL
Похоже, что сортировки в PostgreSQL гораздо менее гибкие. Можно указать только культура / локаль: en_US, de_DEи т.д. Пожалуйста , смотрите их страницу документации для Collation поддержки для деталей. Следовательно, по умолчанию вы получаете специфичные для культуры переопределения, но в противном случае параметры сортировки чувствительны ко всему (что, кстати, не совпадает с «двоичным» сопоставлением).
Вы можете использовать ILIKE (раздел 9.7.1) для получения нечувствительности к регистру, но у них нет аналогичного оператора для чувствительности к акценту. Тем не менее, я обнаружил, что у них есть функция без акцента, которую можно использовать для удаления акцентов и других диакритических знаков. Обратите внимание, что эта функция является дополнительным поставляемым модулем и, следовательно, не обязательно присутствует на каком-либо конкретном сервере PostgreSQL для использования. Эта самая последняя связанная документация гласит:
При сборке из исходного дистрибутива эти компоненты не собираются автоматически, если вы не
создадите цель "world"
...
Если вы используете предварительно упакованную версию PostgreSQL, эти модули обычно предоставляются в виде отдельного подпакета, такого как PostgreSQL-вно.
Пожалуйста, смотрите эту документацию для получения инструкций о том, как получить эту функцию, если у вас ее нет и вы хотите ее получить.
Дополнительную информацию также можно найти в следующем ответе о переполнении стека:
Поддерживает ли PostgreSQL сортировку без учета акцента?
DB2 (IBM)
Подобно Microsoft SQL Server, DB2 имеет два типа сопоставлений:
«Система» Параметры сортировки, которые указаны в следующем формате: SYSTEM_{codepage}_[optional-territory]. Они не очень гибкие и, по-видимому, не поддерживают адаптацию чувствительности к регистру, акцентам или чему-либо еще. Вы можете найти список поддерживаемых сопоставлений здесь: Поддерживаемые коды территорий и кодовые страницы
Объединения на основе алгоритма сопоставления Unicode (UCA). Они действительно поддерживают немного пошива. Пожалуйста, смотрите их страницу сопоставлений на основе алгоритма сопоставления Unicode для получения подробной информации о том, как настроить поведение, соглашение об именовании и список допустимых локалей. Обратите внимание, что в Таблице 1 пример в третьей строке («Уровень дела») начинается с:
Если для атрибута «Уровень дела» установлено значение «Вкл», а для атрибута «Сила» - первичный уровень, акцент будет игнорироваться, но не регистр.
Это именно то, что вы искали. Но, синтаксис для этого есть:
CLDR181_EO_S1. И именно поэтому ваш поиск не нашел ничего, связанного с DB2.
оракул
В Oracle 10g добавлена поддержка сравнения и сортировки без учета акцентов. Тем не мение:
- у них есть только опции для обозначения «нечувствительных» операций:
_CIи_AI
- вы можете указать только один из этих вариантов одновременно
- опция без учета регистра -
_CI- все еще чувствительна к акценту
- опция, нечувствительная к акценту -
_AI- «всегда также нечувствительна к регистру». (цитата из их документации, которая связана ниже)
Пожалуйста, смотрите их страницу документации по лингвистической сортировке и поиску строк для получения более подробной информации и примеров.
SAP ASE (ранее Sybase ASE, также известный как Sybase)
ASE поддерживает одну или несколько из следующих комбинаций чувствительности для каждой локали / набора символов:
- чувствительный к регистру, чувствительный к акценту
- без учета регистра, с акцентом
- без учета регистра, с акцентом, порядок с предпочтением
- без учета регистра, без учета акцента
Вы можете увидеть связь между локалью, набором символов и доступными порядками сортировки на их странице Выбор порядка сортировки по умолчанию . И вы можете увидеть полный список параметров сортировки на странице их имен и идентификаторов .
Их соглашение о присвоении имен сортировки является произвольным в том смысле, что все они состоят из 4-8 символов и пытаются захватить имя локали или кодовую страницу, а также некоторый смысл сортировки. Например:
altnoacc== "CP 850 Alternative - без акцента"
rusdict== "Упорядочение русского словаря"
dynix== "Китайский фонетический порядок"
На странице « Выбор порядка сортировки по Юникоду по умолчанию» есть примечание :
Вы можете добавить порядок сортировки, используя внешние файлы в $/collate/Unicodeкаталоге. Имена и идентификаторы сопоставления хранятся в syscharsets. Имена внешних порядков сортировки в Юникоде не должны вводиться, syscharsetsпрежде чем вы сможете установить порядок сортировки в Юникоде по умолчанию.
...
Внешние заказы на сортировку в Юникоде предоставляются SAP. Не пытайтесь создавать внешние порядки сортировки Unicode.
Неясно, будет ли SAP предоставлять внешний порядок сортировки, учитывающий регистр и нечувствительность к акценту. Может быть, когда-нибудь я напишу им по электронной почте и спросить, можно ли их попросить.
Чтобы получить желаемую комбинацию чувствительности, вы должны иметь возможность создать скалярную пользовательскую функцию для удаления акцентов и других диакритических знаков.
Informix (покупается IBM)
Похоже, что Informix в основном поддерживает сортировку и поведение сравнения по умолчанию. Следовательно, Collations - это только локаль и набор символов. Чувствительность к регистру обрабатывается на уровне базы данных, и по умолчанию они чувствительны к регистру. Вы можете установить базу данных (не таблицу, или столбец, или запрос, или даже предикат) без учета регистра, указав NLSCASE INSENSITIVE в CREATE DATABASEоператоре.
Хотя сопоставление базы данных - локаль и набор символов - может быть переопределено для каждого клиентского соединения, похоже, нет способа переопределить настройку чувствительности к регистру. И, то NLSCASEвариант имеет «NLS» в имени по причине: это влияет только NCHARи NVARCHARданные; CHARи VARCHARвсегда чувствительны к регистру.
Чувствительность к акценту не рассматривается, и нет встроенной функции для удаления акцентов / диакритических знаков.
Соглашение об именовании Informix Collation:
<lang>_<country>.<code set>
где:
<lang> = двухбуквенный или трехбуквенный код языка<country> = двухбуквенный код страны или региона<code set> = кодовая страница, указанная одним из 3 следующих эквивалентных способов:
- имя: 8859-1
- десятичное значение номера IBM CCSID: 819
- шестнадцатеричное значение номера IBM CCSID: 0333
Следовательно, следующие три спецификации локали относятся к одной и той же локали:
- fr_fr.8859-1
- fr_fr.819
- fr_fr.0333
Для получения дополнительной информации, пожалуйста, смотрите: