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
Як видно з діаграми, два з семи RDBMS в основному підтримують операції, залежні від обліку та чутливості до акценту, за допомогою Collations, хоча вони мають різні умови іменування (та кілька інших функціональних відмінностей).
Один RDBMS - PostgreSQL - не підтримує цю комбінацію, але ви все одно можете її досягти, знімаючи акценти за допомогою функції unaccent()надбудови.
Останні чотири RDBMS, два з яких мають схожу конвенцію щодо імен для параметрів, не підтримують цю комбінацію, як і не існує засобів для її виконання, не написавши власну функцію для видалення наголосів / діакритичних знаків. MySQL дозволяє створювати власні Collations, але для цього потрібно додати його до керування джерелом та включити його в процес тестування та розгортання, щоб його можна було застосувати до всіх серверів у будь-яких середовищах (але все-таки дуже крутий і гнучкий варіант) . SAP ASE зазначає, що SAP може поставляти додаткові замовлення на сортування Unicode, але не згадує про те, що вони можуть бути готові надати.
По відношенню до:
Чи є причина для цього чи моя шахта - це лише рідкісний випадок використання?
Я можу сказати, що, роблячи дослідження на цю відповідь, я натрапив на чимало випадків, коли люди, які бажають чутливих до регістру та чутливих до акцентів для MySQL, але мало хто, якщо такі є, запитують потрібну комбінацію.
Я хотів, щоб умова пошуку використовувала чутливе до регістру, але нечутливе до акценту порівняння, але не могло його знайти.
...
це питання є постачальником / версією агностично
Ви не мали успіху в пошуку, оскільки насправді не має сенсу шукати RDBMS на основі специфікації Collation. Ось тільки не так, як працюють колекції. І хоча ви хочете підходити до цього як до агностичного продавця, реальність полягає в тому, що зібрання - принаймні, частина, з якою ми взаємодіємо - є дуже специфічною для продавця, і не завжди вписується в схему, яку ви шукали .
Порівняння і сортування рядків є дуже складним, і існують різні способи виконання цих правил. Одним із методів є створення відображень, які враховують одне або кілька правил. Отже, чотири комбінації чутливих та чутливих до справи та наголосів дорівнювали б чотирьом окремим відображенням. Наприклад, ви бачили це на тій сторінці MSDN для імені зіставлення SQL Server . Якщо прокрутити вниз, ви побачите, що лівий стовпець діаграми - це Sort Order ID. Кожне зіставлення має інший ідентифікатор: SQL_Latin1_General_Cp1_CI_AS= 52 в той час як SQL_Latin1_General_Cp1_CS_AS= 51, хоча різниця полягає лише в чутливості регістру.
Або це може бути на основі правил, наприклад, те, що Unicode пропонує через алгоритм зібрання Unicode (UCA). При такому підході кожному символу за замовчуванням надається одна чи кілька ваг. Тоді кожна культура / локаль може мати можливість змінити будь-яку з цих ваг, або видалити правила, або додати правила. Алгоритм враховує будь-які правила, характерні для локальної локалізації, а потім потенційно маніпулює цими вагами на основі будь-яких обраних варіантів (чутливість, яка випадає першою під час виконання залежних від регістру сортів тощо). Це одна з причин, чому сортування Unicode відбувається трохи повільніше, ніж сортування Unicode.
Щоб зрозуміти, скільки варіантів існує насправді (тобто фактична складність), перегляньте цю демонстрацію з проекту ICU (International Components for Unicode):
Демографічний показник співпраці ICU
Є 8 окремих параметрів , щоб вказати, і деякі з них отримують представлені в декількох елементів специфікації Collation ім'я , що ви думаєте (наприклад CS, CI, AS, AIі т.д.). Зважаючи на те, скільки варіантів існує, використання підходу до файлу відображення, де у кожної комбінації є свій ідентифікатор, вийде багато тисяч файлів. Багатьом із цих файлів потрібно буде оновлюватись щоразу, коли на тих чи інших мовах є зміни чи коли виявляються помилки. Можливо, тому в SQL Server 2012 є лише 75 таких типів зіставлень (тобто тих, у яких імена починаються з SQL_). Тому немає комбінації для _CS_AI.
І причина, чому ви не змогли знайти цю комбінацію для колекцій, заснованих на UCA? Що ж, у SQL Server 2012 є 3810 зібрань, які не починаються SQL_, тому загалом 3885 зібрань. Цей список, здається, занадто довгий, щоб його перерахувати повністю на веб-сторінці. Але це не повністю пояснює, чому ви не могли знайти цю комбінацію для інших постачальників.
Крім того, що вже згадувалося (тобто занадто багато комбінацій для реалізації та занадто багато реалізацій для переліку), вам все одно потрібно боротися з конкретними постачальниками реалізаціями. Значення: не всі постачальники дозволяють пристосувати всі ці варіанти, і в першу чергу не існує стандартної угоди про іменування для Collations. Крім того, не всі постачальники розглядають параметри сортування як частину Collation: PostgreSQL Collations - це замовлення за замовчуванням для обраної мови, і вам потрібно скористатися, ILIKEщоб порівняти нечутливе до регістру порівняння. Див. Нижче інформацію про постачальника.
SQL Server (Microsoft)
Відмінність того, що ви бачите на цих двох сторінках документації MSDN, і запитом, наданим @MartinSmith в коментарі до питання (трохи переглянутому нижче):
SELECT *
FROM sys.fn_helpcollations()
WHERE [name] LIKE '%[_]CS[_]AI%';
полягає в тому, що ці дві сторінки MSDN конкретно посилаються на дуже застарілі зібрання на сервері SQL Server, тоді як порівняння, які з’являються в результаті цього запиту (з них 888 - на SQL Server 2012, SP3) - це Windows Collations.
Починаючи з SQL Server 2000, старі зібрання SQL Server (створені до того, як SQL Server зможе вступити в Windows Collations) застаріли і не оновлюються новими правилами або функціональними можливостями. Наприклад, починаючи з SQL Server 2012, додано набір зіставлень, які підтримують належну обробку вбудованих функцій для додаткових символів (тобто решта символів UTF-16 за межами "базової" 65 536 символів, початково визначених в UCS-2 ). Ці нові параметри сортування закінчуються _SC(як в S upplementary C Символів).
Найкраще не використовувати зібрання SQL Server - ті, у яких імена починаються з SQL_. Отже, у вас є доступ до безлічі зібрань, які підтримують комбінацію варіантів, які ви шукаєте (наприклад, чутливі до регістру та чутливі до акцентів). Коли вони є, також найкраще використовувати один кінець _SC, якщо він має всі інші варіанти, які ви хочете.
Хоча SQL Server використовує _CS_AIконвенцію про іменування, немає списку всіх зібрань Windows 3810 (станом на SQL Server 2012). Існує лише сторінка з ім'ям зібрання Windows, яка перелічує всі локальні версії та версії, і як діє умова іменування, але це все.
SQL Server також підтримує змінення чутливості як Width, так і Kana.
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_aiCollation. Тим НЕ менше, сервер MySQL 5.5.50 , що у мене є доступ до не має зіставлення з більш ніж одним суфіксом, і тільки суфікси я бачу , є: _cs, _ciі _binчерез 198 повних Collations. Я використовував команду SHOW COLLATION, щоб перерахувати їх.
Отже, хоча це звучить як MySQL використовує подібний режим іменування (принаймні, що стосується цих двох варіантів), я не можу знайти зіставлення, що відповідає тому, що ви шукаєте. Однак, можливо, можна зняти наголоси (та інші діакритичні позначки) та використати _csпорівняння, щоб отримати те, що ви хочете (подібне до того, як ви це зробите в PostgreSQL - див. Нижче). Але я не впевнений у цьому варіанті і не маю часу на подальші дослідження.
АБО , ви можете створити свою власну колекцію, щоб робити саме те, що ви хочете. На відміну від інших RDBMS, видається, що MySQL робить досить простим додавання власних Collations, і в цьому випадку ви повністю контролюєте вагомість кожного символу. Будь ласка, дивіться Додавання простого зібрання до 8-бітового набору символів та додавання колекції UCA до набору символів Unicode для отримання більш детальної інформації.
Для отримання додаткової інформації про те, як MySQL обробляє різні типи зібрань, перегляньте їх сторінку Типи впровадження Collation .
PostgreSQL
Збори в PostgreSQL здаються набагато менш гнучкими. Можна вказати тільки культура / локаль: en_US, de_DEі т.д. ласка , дивіться їх сторінку документації для Collation підтримки для деталей. Отже, за замовчуванням ви отримуєте відміни для конкретних культур, але в іншому випадку Collations є чутливим до всього (що, до речі, не є збігом "двійкового").
Ви можете використовувати ILIKE (розділ 9.7.1), щоб отримати чутливість до регістру, але вони не мають аналогічного оператора для чутливості до акцентів. Однак я виявив, що вони мають непривабливу функцію, яку можна використовувати для викреслення акцентів та інших діакритичних знаків. Зауважте, що ця функція є додатковим модулем, що постачається, а тому необов'язково присутній на будь-якому конкретному сервері PostgreSQL, який слід використовувати. Ця нещодавно пов'язана документація зазначає:
Під час побудови з вихідного дистрибутива ці компоненти не будуються автоматично, якщо ви не будуєте ціль "світу"
...
Якщо ви використовуєте попередньо упаковану версію PostgreSQL, ці модулі, як правило, стають доступними як окремий підпакет, наприклад postgresql-contrib.
Будь ласка, дивіться цю документацію для інструкцій, як отримати цю функцію, якщо у вас її немає та хочете.
Додаткову інформацію можна знайти в наступній відповіді на переповнення стека:
Чи підтримує PostgreSQL "нечутливі до акценту" порівняння?
DB2 (IBM)
Подібно до Microsoft SQL Server, DB2 має два типи зібрань:
«Система» Параметри сортування, які вказані в наступному форматі: SYSTEM_{codepage}_[optional-territory]. Вони не дуже гнучкі, і, здається, не підтримують чутливість до випадку, акцентів чи іншого. Список підтримуваних зібрань можна знайти тут: Підтримувані коди територій та кодові сторінки
Порівнювання, засновані на алгоритмі кодування Unicode (UCA). Вони дуже підтримують пошиття одягу. Перегляньте їхню сторінку зіставлень, засновану на алгоритмі Unicode Collation, щоб дізнатись, як налаштувати поведінку, умову іменування та список дійсних локалів. Зверніть увагу, що в таблиці 1 приклад у третьому рядку ("Рівень справ") починається з:
Якщо встановити атрибут Level Case на on, а атрибут Strength - на первинному рівні, він буде ігнорувати наголос, але це не так.
Це саме те, що ви шукали. Але, синтаксис для цього є:
CLDR181_EO_S1. І саме тому ваш пошук не знайшов нічого, що стосується DB2.
Oracle
Oracle 10g додав підтримку для порівняння та сортування, що не чутливі до акцентів. Однак:
- у них є лише варіанти позначати "нечутливі" операції:
_CIі_AI
- ви можете одночасно вказати лише один із цих варіантів
- нечутливий до регістру варіант -
_CI- все ще чутливий до акценту
- варіант - нечутливий до акценту -
_AI- "також завжди нечутливий до регістру". (цитується з їх документації, яка посилається нижче)
Будь ласка , дивіться їх Searching лінгвістичну Сортування і струнних сторінку документації для отримання більш детальної інформації та прикладів.
SAP ASE (раніше Sybase ASE, він же Sybase)
ASE підтримує одну або більше таких комбінацій чутливості для кожного набору локалів / символів:
- регістр, чутливість до акценту
- нечутливі до регістру, чутливі до акцентів
- нечутливі до регістру, чутливі до акцентів, замовлення з уподобанням
- регістро-нечутливий, акцент-нечутливий
Ви можете побачити залежність між локальним, набором символів та доступними порядками сортування на їхній сторінці Вибір сторінки " Порядок сортування за замовчуванням ". Повний список зібрань ви можете побачити на сторінці їх імен та ідентифікацій .
Їх домовленість щодо іменування зіставлення довільна тим, що вони всі 4 - 8 символів і намагаються захопити ім'я локалі або кодову сторінку та деякий сенс сортування. Наприклад:
altnoacc== "CP 850 Альтернатива - без наголосу"
rusdict== "Замовлення російського словника"
dynix== "Китайське фонетичне впорядкування"
На їх сторінці Вибір сторінки за замовчуванням сортування Unicode зазначається:
Ви можете додати замовлення на сортування за допомогою зовнішніх файлів у $/collate/Unicodeкаталозі. Імена та ідентифікатори зіставлення зберігаються в syscharsets. Імена зовнішніх замовлень сортування Unicode не повинні міститись, syscharsetsперш ніж ви зможете встановити порядок сортування Unicode за замовчуванням.
...
Зовнішні замовлення на сортування Unicode надаються SAP. Не намагайтеся створити зовнішні замовлення на сортування Unicode.
Незрозуміло, чи постачав би SAP порядок зовнішнього сортування, щоб забезпечити чутливість до обліку та акцентування. Можливо, колись я їм надішлю електронний лист і запитаю, чи можна когось запитати.
Для того, щоб отримати бажану комбінацію чутливості, ви повинні мати можливість створити скалярну визначену користувачем функцію, щоб позбавити акценти та інші діакритичні позначки.
Informix (куплений IBM)
Здається, Informix здебільшого просто підтримує поведінку сортування та порівняння за замовчуванням для Collation. Отже, зібрання - це лише набір локалів та символів. Чутливість до обліку обробляється на рівні бази даних, а за замовчуванням вони залежать від регістру. Ви можете встановити базу даних (не таблицю, стовпець, запит або навіть присудок), щоб не залежати від регістру, вказавши в CREATE DATABASEоператорі NLSCASE INSENSITIVE .
Хоча Збір даних у базі даних - локалі та наборі символів - може бути замінено на підключення клієнта, схоже, не існує способу змінити налаштування чутливості до регістру. І, то NLSCASEваріант має «NLS» в імені через: це впливає тільки NCHARі NVARCHARдані; CHARі VARCHARзавжди залежать від регістру.
Чутливість до акцентів не адресована, а також немає вбудованої функції для позбавлення наголосів / діакритичних знаків.
Конвенція про іменування збірки Informix:
<lang>_<country>.<code set>
де:
<lang> = 2-літерний або 3-літерний код мови<country> = двоцифровий код країни чи регіону<code set> = кодова сторінка, вказана одним із 3 наступних еквівалентних способів:
- назва: 8859-1
- десяткове значення номера IBM CCSID: 819
- шістнадцяткове значення номера IBM CCSID: 0333
Отже, наступні три специфікації локалі стосуються точно такої самої локалі:
- fr_fr.8859-1
- fr_fr.819
- fr_fr.0333
Для отримання додаткової інформації дивіться: