Czy jakiś system DBMS ma sortowanie, w którym rozróżniana jest wielkość liter i nie jest uwzględniany akcent?

Uwaga: to pytanie jest niezależne od dostawcy / wersji

Wydaje mi się, że jako mówca (maszynistka, pisarz) języka angielskiego rozsądne jest oczekiwanie, że słowa będą odpowiednio ułożone w literę, ale niekoniecznie mają właściwe akcenty idące w dobrym kierunku:

jak zastanawiałem się w tete-a-tete z Chloe maitre d'hotel w restauracji Champs-Elysees, czekając, aż garcon przyniesie mój smażony pasztet z jalapeno ...

Masz z tym pomysł.

Więc dzisiaj pomyślałem, że chcę, aby warunek wyszukiwania używał sortowania uwzględniającego wielkość liter, ale niewrażliwego na akcent, ale nie mogłem go znaleźć. Czy jest ku temu dobry powód, czy mój jest tylko rzadkim przypadkiem użycia?

Oto przykład dokumentacji, na którą patrzyłem (choć myślę, że niezależny dostawca / wersja):

Nazwa sortowania programu SQL Server (SQL Server 2008 R2)

TL; DR

Nie ma czegoś takiego jak „niezależny od dostawcy” widok Kolacji, ani nawet „niezależny od wersji”, ponieważ ich implementacje - w tym aspekty, które można uczynić niewrażliwymi, a ich konwencje nazewnictwa - są specyficzne dla dostawcy i zmieniają się z czasem .

Oto podsumowanie tego, co znalazłem, a szczegóły znajdują się w dłuższej sekcji poniżej linii:

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

Jak widać na wykresie, dwa z siedmiu RDBMSs zrobić natywnie wsparcie „wielkość liter i operacje Akcent niewrażliwe” poprzez Konfrontacje, choć mają różne konwencje nazewnictwa (i kilka innych różnic funkcjonalnych).

Jeden RDBMS - PostgreSQL - natywnie nie obsługuje tej kombinacji, ale nadal można to osiągnąć, usuwając akcenty za pomocą unaccent()funkcji dodatkowej.

Ostatnie cztery RDBMS, z których dwa mają podobną konwencję nazewnictwa dla opcji, ani natywnie nie obsługują tej kombinacji, ani nie wydaje się, że istnieje sposób na osiągnięcie tego bez pisania własnej funkcji usuwania akcentów / znaków diakrytycznych. MySQL pozwala na tworzenie własnych zestawień, ale wymaga to dodania go do kontroli źródła i włączenia go do procesu testowania i wdrażania, aby można go było zastosować na wszystkich serwerach we wszystkich środowiskach (ale nadal jest to bardzo fajna i elastyczna opcja) . SAP ASE wspomina, że ​​SAP może dostarczyć dodatkowe zamówienia sortowania Unicode, ale nie wspomina o tym, co mogą być skłonni dostarczyć.

Z pozdrowieniami dla:

Czy jest ku temu dobry powód, czy mój jest tylko rzadkim przypadkiem użycia?

Mogę powiedzieć, że robiąc badania dla tej odpowiedzi, natknąłem się na wiele osób, które nie chcą rozróżniać wielkości liter i zwracają uwagę na akcent na MySQL, ale niewielu, jeśli w ogóle, prosi o pożądaną kombinację.

Chciałem, aby warunek wyszukiwania używał sortowania uwzględniającego wielkość liter, ale nie uwzględniającego akcentu, ale nie mogłem go znaleźć.
...
to pytanie jest niezależne od dostawcy / wersji

Nie powiodło się Twoje wyszukiwanie, ponieważ tak naprawdę nie ma sensu szukać RDBMS na podstawie specyfikacji sortowania. Po prostu nie tak działają Collations. I chociaż chcesz podejść do tego jako niezależny od dostawcy, rzeczywistość jest taka, że ​​Kolacje - przynajmniej ta część, z którą wchodzimy w interakcje - są bardzo specyficzne dla dostawców i nie zawsze pasują do schematu, którego szukasz .

Porównanie i sortowanie ciągów jest bardzo złożone i istnieją różne sposoby wykonywania tych reguł. Jedną z metod jest posiadanie mapowań, które uwzględniają jedną lub więcej reguł. Zatem cztery kombinacje Czułości i Niewrażliwości dla Case i Accents byłyby równe czterem oddzielnym mapowaniom. Na przykład widziałeś to na tej stronie MSDN dla SQL Server Collation Name . Jeśli przewiniesz w dół, zobaczysz, że lewa kolumna wykresu to Sort Order ID. Każde zestawienie ma inny identyfikator: SQL_Latin1_General_Cp1_CI_AS= 52, natomiast SQL_Latin1_General_Cp1_CS_AS= 51, chociaż jedyną różnicą jest rozróżnianie wielkości liter.

Lub może być oparty na regułach, takich jak to, co oferuje Unicode za pomocą algorytmu UCA (Unicode Collation Algorithm). W tym podejściu każda postać ma domyślnie jeden lub więcej obciążników. Następnie każda kultura / ustawienie regionalne ma możliwość zastąpienia dowolnej z tych wag, usunięcia reguł lub dodania reguł. Algorytm uwzględnia wszelkie reguły specyficzne dla ustawień regionalnych, a następnie potencjalnie manipuluje tymi wagami w oparciu o dowolne wybrane opcje (czułość, która przypadek jest najważniejsza przy sortowaniu z rozróżnianiem wielkości liter itp.). Jest to jeden z powodów, dla których sortowanie w standardzie Unicode jest nieco wolniejsze niż sortowanie w standardzie innym niż Unicode.

Aby dowiedzieć się, ile naprawdę istnieje opcji (tj. Faktyczna złożoność), sprawdź to demo z projektu ICU (International Components for Unicode):

ICU Collation Demo

Istnieje 8 oddzielnych opcji, aby określić, a niektóre z nich uzyskać reprezentowane w wielu elementów specyfikacji nazwy Sortowanie że myślisz (np CS, CI, AS, AI, etc). Biorąc pod uwagę liczbę odmian, zastosowanie metody pliku odwzorowania, w którym każda kombinacja ma swój własny identyfikator, dałoby wiele tysięcy plików. Wiele z tych plików musiałoby zostać zaktualizowanych za każdym razem, gdy nastąpią zmiany w tych konkretnych językach lub gdy zostaną znalezione błędy. Prawdopodobnie dlatego w programie SQL Server 2012 jest tylko 75 tego rodzaju zestawień (tj. O nazwach rozpoczynających się od SQL_). Stąd brak połączenia dla _CS_AI.

A dlaczego nie udało Ci się znaleźć takiej kombinacji dla zestawień opartych na UCA? Cóż, w SQL Server 2012 jest 3810 zestawień, które się nie zaczynają SQL_, więc 3885 zestawień łącznie. Ta lista wydaje się zbyt długa, aby można ją było w pełni wyliczyć na stronie internetowej. Ale to nie wyjaśnia w pełni, dlaczego nie można znaleźć tej kombinacji dla innych dostawców.

Poza tym, co już wspomniano (tj. Zbyt wiele kombinacji do zaimplementowania i zbyt wiele implementacji do wypisania), nadal musisz walczyć z implementacjami specyficznymi dla dostawcy. Znaczenie: nie wszyscy dostawcy pozwalają na dostosowanie wszystkich tych opcji, a przede wszystkim nie ma standardowej konwencji nazewnictwa dla zestawień. Ponadto nie wszyscy dostawcy traktują opcje sortowania jako część sortowania: Sortowania PostgreSQL są domyślnie uporządkowane dla wybranych ustawień regionalnych i należy użyć tego, ILIKEaby uzyskać porównanie bez rozróżniania wielkości liter. Zobacz poniżej informacje specyficzne dla dostawcy.

SQL Server (Microsoft)

Różnica między tym, co widzisz na tych dwóch stronach dokumentacji MSDN, a zapytaniem podanym przez @MartinSmith w komentarzu do pytania (nieco zmienionego poniżej):

SELECT *
FROM   sys.fn_helpcollations()
WHERE  [name] LIKE '%[_]CS[_]AI%';

jest to, że te dwie strony MSDN odnoszą się konkretnie do bardzo przestarzałych zestawień SQL Server, podczas gdy zestawienia, które pojawiają się w wyniku tego zapytania (888 z nich od SQL Server 2012, SP3), są zestawieniami Windows.

Począwszy od SQL Server 2000, starsze SQL Server Collations (utworzone przed uruchomieniem przez SQL Server połączenia z Windows Collations) są przestarzałe i nie są aktualizowane o nowe reguły ani funkcje. Na przykład, począwszy od SQL Server 2012, dodano zestaw sortowań, które obsługują poprawną obsługę wbudowanych funkcji dla znaków uzupełniających (tj. Pozostałe znaki UTF-16 poza „podstawowymi” 65 536 znakami wstępnie zdefiniowanymi w UCS-2 ). Te nowsze sortowania kończą się na _SC(jak w S dodatkowych znakach C ).

Najlepiej nie używać kolacji SQL Server - tych o nazwach rozpoczynających się od SQL_. Dlatego masz dostęp do wielu zestawień, które obsługują kombinację opcji, których szukasz (tj. Rozróżnia wielkość liter i rozróżnia akcenty). Gdy tylko jest to możliwe, najlepiej jest używać jednego końca, _SCo ile ma on wszystkie inne opcje, których potrzebujesz.

Podczas gdy SQL Server korzysta z _CS_AIkonwencji nazewnictwa, nie ma listy wszystkich 3810 (od SQL Server 2012) Windows Collations. Jest tylko strona Windows Collation Name, która zawiera listę wszystkich ustawień narodowych i wersji oraz sposób działania konwencji nazewnictwa, ale to wszystko.

SQL Server obsługuje także przełączanie czułości na szerokość i Kana.

MySQL (zakupiony przez Oracle)

MySQL w wersji 5.7, dokumentacja stwierdza, że nie wspierają _ai, _as, _ci, i _csprzyrostków (i _binkompletności), ale również stanowi, że:

W przypadku niebinarnych nazw zestawień, które nie określają czułości akcentu, jest ona określana na podstawie rozróżniania wielkości liter. Oznacza to, że jeśli nazwa sortowania nie zawiera _ailub _as, _ciw nazwie implikuje _aii _csw nazwie implikuje _as.

Na przykład, latin1_general_cirozróżnia małe i wielkie litery (i nieważne na akcent, niejawnie), latin1_general_csrozróżnia małe i duże litery (i niejawnie)

To z pewnością implikuje, że można mieć latin1_general_cs_aizestawienie. Jednak serwer MySQL 5.5.50, że mam dostęp do nie ma żadnych sortowania z więcej niż jednym przyrostkiem, a jedynym przyrostki widzę to: _cs, _cii _bincałej sumy 198 Konfrontacje. Użyłem polecenia SHOW COLLATION, aby je wyświetlić.

Tak więc, choć brzmi to tak, jakby MySQL używa podobnej konwencji nazewnictwa (przynajmniej w zakresie tych dwóch opcji), nie mogę znaleźć sortowania pasującego do tego, czego szukasz. Jednak może być możliwe usunięcie akcentów (i innych znaków diakrytycznych) i użycie _cssortowania, aby uzyskać to, czego chcesz (podobnie jak w PostgreSQL - patrz poniżej). Nie jestem jednak pewien tej opcji i nie mam w tej chwili czasu na dalsze badania.

LUB możesz stworzyć swoje własne sortowanie, aby robić dokładnie to, co chcesz. W przeciwieństwie do innych RDBMS, MySQL sprawia, że ​​dodawanie własnych sortowań jest dość proste, w którym to przypadku masz pełną kontrolę nad ważeniem każdego znaku. Aby uzyskać więcej informacji, zobacz Dodawanie prostej zestawienia do 8-bitowego zestawu znaków i Dodawanie zestawienia UCA do zestawu znaków Unicode .

Aby uzyskać więcej informacji o tym, jak MySQL obsługuje różne typy zestawień, zobacz ich stronę Typy implementacji zestawień .

PostgreSQL

Sortowanie w PostgreSQL wydaje się być znacznie mniej elastyczne. Podać tylko kultura / locale: en_US, de_DE, itd. Proszę zobaczyć ich stronę dokumentacja dla zestawień Wsparcie dla szczegółów. Dlatego domyślnie otrzymujesz przesłonięcia specyficzne dla kultury, ale w przeciwnym razie Kolacje są wrażliwe na wszystko (co zresztą nie jest tym samym, co sortowanie „binarne”).

Możesz użyć ILIKE (sekcja 9.7.1), aby uzyskać niewrażliwość na wielkość liter, ale nie mają one podobnego operatora dla czułości akcentu. Odkryłem jednak, że mają one funkcję bezcenności, której można używać do usuwania akcentów i innych znaków diakrytycznych. Należy pamiętać, że ta funkcja jest dodatkowym dostarczonym modułem i dlatego niekoniecznie jest obecna w żadnym konkretnym serwerze PostgreSQL do użycia. W najnowszej połączonej dokumentacji stwierdzono:

Podczas budowania z dystrybucji źródłowej te komponenty nie są budowane automatycznie, chyba że zbudujesz cel „światowy”
...
Jeśli używasz paczkowanej wersji PostgreSQL, moduły te są zazwyczaj udostępniane jako osobny sub-pakiet, taki jak postgresql-contrib.

Zapoznaj się z tą dokumentacją, aby uzyskać instrukcje, jak uzyskać tę funkcję, jeśli jej nie masz i chcesz.

Więcej informacji można również znaleźć w następującej odpowiedzi Przepełnienie stosu:

Czy PostgreSQL obsługuje sortowanie „niewrażliwe na akcenty”?

DB2 (IBM)

Podobnie jak Microsoft SQL Server, DB2 ma dwa typy sortowania:

• „System” Konfrontacje, które są wyszczególnione w następującym formacie: SYSTEM_{codepage}_[optional-territory]. Nie są one zbyt elastyczne i nie wydają się wspierać dostosowania czułości do obudowy, akcentów lub czegokolwiek. Listę obsługiwanych zestawień można znaleźć tutaj: Obsługiwane kody terytorium i strony kodowe

• Ujednolicenia oparte na algorytmie sortowania Unicode (UCA). Obsługują one sporo dostosowywania. Proszę zobaczyć ich sortowania w oparciu Unicode Collation Algorithm aktualizacja informacji o tym, jak skonfigurować zachowanie, konwencja nazewnictwa, a lista ważnych lokalizacjach. Należy zauważyć, że w tabeli 1 przykład w trzecim wierszu („Poziom przypadku”) zaczyna się od:

  Ustawienie na wartość atrybutu Case Case i Atrybut Strength na poziom podstawowy zignoruje akcent, ale nie wielkość liter.

  Właśnie tego szukałeś. Ale składnia to: CLDR181_EO_S1. I dlatego podczas wyszukiwania nie znaleziono niczego związanego z DB2.

Wyrocznia

Oracle 10g dodał obsługę wykonywania niewrażliwych na akcentowanie porównań i sortowania. Jednak:

• mają tylko opcje oznaczania „niewrażliwych” operacji: _CIi_AI
• możesz określić tylko jedną z tych opcji jednocześnie
• opcja bez rozróżniania wielkości liter - _CI- nadal jest wrażliwa na akcent
• opcja niewrażliwa na akcent - _AI- „zawsze rozróżnia małe i wielkie litery”. (cytowany z ich dokumentacji, do której link znajduje się poniżej)

Proszę zobaczyć ich Wyszukany językowa sortowania i String aktualizacja dokumentacji dla więcej szczegółów i przykładów.

SAP ASE (wcześniej Sybase ASE, alias Sybase)

ASE obsługuje jedną lub więcej następujących kombinacji czułości dla każdego ustawienia narodowego / zestawu znaków:

• rozróżnia małe i wielkie litery, akcentuje
• nie rozróżnia wielkości liter, rozróżnia akcenty
• rozróżnianie wielkości liter, rozróżnianie akcentów, porządek z preferencją
• bez rozróżniania wielkości liter, bez akcentu

Związek między ustawieniami regionalnymi, zestawem znaków i dostępnymi porządkami sortowania można zobaczyć na stronie Wybór domyślnej kolejności sortowania . I możesz zobaczyć pełną listę Sortowań na stronie Nazwy i identyfikatory sortowania .

Ich konwencja nazewnictwa sortowania jest arbitralna, ponieważ wszystkie mają od 4 do 8 znaków i próbują uchwycić nazwę ustawień regionalnych lub stronę kodową oraz pewne poczucie sortowania. Na przykład:

altnoacc== „CP 850 Alternative - no accent”
rusdict== „Rosyjski słownik zamawiania”
dynix== „Chiński porządek fonetyczny”

Na ich stronie Wybieranie domyślnego porządku sortowania Unicode znajduje się notatka z następującą informacją :

Możesz dodać porządki sortowania, używając plików zewnętrznych w $/collate/Unicodekatalogu. Nazwy i identyfikatory sortowania są przechowywane w syscharsets. Nazwy zewnętrznych porządków sortowania Unicode nie muszą znajdować się syscharsetsprzed ustawieniem domyślnego porządku sortowania Unicode.
...
Zewnętrzne porządki sortowania Unicode są dostarczane przez SAP. Nie próbuj tworzyć zewnętrznych zamówień sortowania Unicode.

Nie jest jasne, czy SAP dostarczy zewnętrzne sortowanie, aby uwzględnić rozróżnianie wielkości liter i rozróżnianie liter . Może kiedyś wyślę je e-mailem i zapytam, czy można o nie poprosić.

Aby uzyskać pożądaną kombinację wrażliwości, powinieneś być w stanie utworzyć skalarną funkcję zdefiniowaną przez użytkownika, aby usunąć akcenty i inne znaki diakrytyczne.

Informix (zakupiony przez IBM)

Wydaje się, że Informix obsługuje po prostu domyślne zachowanie sortowania i porównywania sortowania. Dlatego zestawienia to tylko ustawienia regionalne i zestaw znaków. Rozróżnianie wielkości liter jest obsługiwane na poziomie bazy danych i domyślnie rozróżniają wielkość liter. Można ustawić, aby baza danych (nie tabela, kolumna, zapytanie, a nawet predykat) nie rozróżniała wielkości liter, określając w CREATE DATABASEinstrukcji NLSCASE INSENSITIVE .

Podczas gdy sortowanie bazy danych - ustawienia regionalne i zestaw znaków - można zastąpić dla każdego połączenia klienta, wydaje się, że nie ma sposobu na zastąpienie ustawienia rozróżniania wielkości liter. Oraz, z NLSCASEopcja ma „NLS” w nazwie nie bez powodu: to dotyczy tylko NCHARi NVARCHARdanych; CHARi VARCHARzawsze uwzględniają wielkość liter.

Czułość akcentu nie jest uwzględniona, ani nie ma wbudowanej funkcji usuwania akcentów / znaków diakrytycznych.

Konwencja nazewnictwa Informix Collation to:

<lang>_<country>.<code set>

gdzie:

• <lang> = 2-literowy lub 3-literowy kod języka
• <country> = dwuliterowy kod kraju lub regionu
• <code set> = strona kodowa określona na jeden z 3 równoważnych sposobów:
  • nazwa: 8859-1
  • wartość dziesiętna numeru IBM CCSID: 819
  • wartość szesnastkowa numeru IBM CCSID: 0333

Dlatego wszystkie trzy następujące specyfikacje ustawień narodowych odnoszą się do dokładnie tego samego ustawienia narodowego:

• fr_858-1-1
• fr_fr.819
• fr_fr.0333

Aby uzyskać więcej informacji, zobacz:

• Podręcznik użytkownika dla IBM Informix International Language Supplement
• Plik rejestru IBM Informix (Windows)

Nazwa opcji Opis NLS_LANG Bieżący język, terytorium i zestaw znaków bazy danych, które są określone przez parametry globalizacji dla całej sesji. NLS_LANGUAGE Bieżący język sesji. NLS_SORT Sekwencja wartości znaków używanych podczas sortowania lub porównywania tekstu.

Aby sprawdzić bieżące ustawienia NLS, wpisz:

wybierz * z v $ NLS_PARAMETERS;