TL; DR
Es gibt weder eine "herstellerunabhängige" Sicht auf Kollationen noch eine "versionsunabhängige" Sicht, da ihre Implementierungen - einschließlich der Aspekte, die unempfindlich gemacht werden können, und ihrer Namenskonventionen - herstellerspezifisch sind und sich im Laufe der Zeit ändern .
Hier ist eine Zusammenfassung dessen, was ich gefunden habe, und die Details befinden sich im längeren Abschnitt unter der Zeile:
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
Wie Sie im Diagramm sehen können, unterstützen zwei der sieben RDBMS nativ "Groß- und Kleinschreibung und Akzentunabhängigkeit" -Operationen über Sortierungen, obwohl sie unterschiedliche Namenskonventionen (und verschiedene andere funktionale Unterschiede) haben.
Ein RDBMS - PostgreSQL - unterstützt diese Kombination von Haus aus nicht, aber Sie können sie dennoch erreichen, indem Sie die Akzente mit der unaccent()Zusatzfunktion entfernen.
Die letzten vier RDBMS, von denen zwei eine ähnliche Namenskonvention für die Optionen haben, unterstützen diese Kombination weder von Haus aus, noch scheint es ein Mittel zu geben, dies zu erreichen, ohne Ihre eigene Funktion zum Entfernen der Akzente / diakritischen Zeichen zu schreiben. Mit MySQL können Sie Ihre eigenen Kollatierungen erstellen. Dazu müssen Sie sie jedoch der Quellcodeverwaltung hinzufügen und in Ihren Test- und Bereitstellungsprozess integrieren, damit sie auf alle Server in allen Umgebungen angewendet werden können (aber immer noch eine sehr coole und flexible Option). . SAP ASE erwähnt, dass SAP zusätzliche Unicode-Sortierreihenfolgen bereitstellen kann , gibt jedoch nicht an, welche Bereitschaft besteht.
In Bezug auf:
Gibt es einen guten Grund dafür oder ist meiner nur ein seltener Anwendungsfall?
Ich kann sagen, dass ich bei der Recherche nach dieser Antwort auf viele Fälle gestoßen bin, in denen Groß- und Kleinschreibung und Akzente für MySQL nicht berücksichtigt werden sollen, aber nur wenige, wenn überhaupt, nach Ihrer gewünschten Kombination gefragt haben.
Ich wollte, dass eine Suchbedingung eine Sortierung verwendet, bei der die Groß- und Kleinschreibung beachtet, der Akzent jedoch nicht beachtet wird, konnte aber keine finden.
...
diese Frage ist Hersteller- / Versionsunabhängig
Sie waren bei Ihrer Suche erfolglos, da es nicht wirklich sinnvoll ist, nach einem RDBMS auf der Grundlage einer Kollatierungsspezifikation zu suchen. So funktionieren Collations einfach nicht. Und während Sie dies als herstellerunabhängig betrachten möchten, ist die Realität, dass Kollatierungen - zumindest der Teil, mit dem wir interagieren - sehr herstellerspezifisch sind und nicht immer in das Schema passen, nach dem Sie gesucht haben .
Der Vergleich und die Sortierung von Zeichenfolgen sind sehr komplex, und es gibt verschiedene Möglichkeiten, diese Regeln auszuführen. Eine Methode besteht darin, Zuordnungen zu erstellen, die eine oder mehrere Regeln berücksichtigen. Daher würden die vier Kombinationen von Sensitiv und Insensitiv für Groß- und Kleinschreibung und Akzente vier getrennten Zuordnungen entsprechen. Beispielsweise haben Sie dies auf dieser MSDN-Seite für den SQL Server-Sortierungsnamen gesehen . Wenn Sie nach unten scrollen, sehen Sie, dass die linke Spalte des Diagramms die ist Sort Order ID. Jede Kollation hat eine andere ID:SQL_Latin1_General_Cp1_CI_AS = 52 while SQL_Latin1_General_Cp1_CS_AS= 51, obwohl der einzige Unterschied in der Groß- und Kleinschreibung liegt.
Oder es kann regelbasiert sein, z. B. was Unicode über den Unicode Collation Algorithm (UCA) anbietet. Bei diesem Ansatz erhält jedes Zeichen standardmäßig eine oder mehrere Gewichte. Anschließend hat jede Kultur / jedes Gebietsschema die Möglichkeit, eine dieser Gewichte zu überschreiben, Regeln zu entfernen oder Regeln hinzuzufügen. Der Algorithmus berücksichtigt alle für das Gebietsschema spezifischen Regeln und manipuliert diese Gewichte möglicherweise basierend auf den ausgewählten Optionen (Empfindlichkeit, wobei bei Sortierungen, bei denen die Groß- und Kleinschreibung berücksichtigt wird, der Groß- und Kleinschreibung der Vorrang eingeräumt wird usw.). Dies ist einer der Gründe, warum die Unicode-Sortierung etwas langsamer ist als die Nicht-Unicode-Sortierung.
Sehen Sie sich diese Demo aus dem ICU-Projekt (International Components for Unicode) an, um einen Eindruck davon zu bekommen, wie viele Optionen es tatsächlich gibt (dh wie komplex sie tatsächlich sind):
ICU Collation Demo
Es gibt 8 verschiedene Optionen zu spezifizieren, und einige von ihnen erhalten in mehrere Elemente der Kollatierungsname Spezifikation repräsentiert , dass Sie denken (zB CS, CI, AS, AI, etc.). Angesichts der Anzahl der Variationen würde die Verwendung des Mapping-Datei-Ansatzes, bei dem jede Kombination eine eigene ID hat, zu vielen tausend Dateien führen. Viele dieser Dateien müssten aktualisiert werden, wenn Änderungen in diesen bestimmten Sprachen vorgenommen werden oder wenn Fehler gefunden werden. Dies ist wahrscheinlich der Grund, warum es in SQL Server 2012 nur 75 Sortierfolgen dieser Art gibt (dh Sortierfolgen mit Namen, die mit beginnen)SQL_ ). Daher keine Kombination für _CS_AI.
Und der Grund, warum Sie diese Kombination für die UCA-basierten Kollationen nicht finden konnten? Nun, es gibt 3810 Kollatierungen in SQL Server 2012, die nicht mit "" beginnen SQL_, also insgesamt 3885 Kollatierungen. Diese Liste scheint zu lang zu sein, um auf einer Webseite vollständig aufgelistet zu werden. Dies erklärt jedoch nicht vollständig, warum Sie diese Kombination für andere Anbieter nicht finden konnten.
Über das bereits Erwähnte hinaus (dh zu viele Kombinationen zum Implementieren und zu viele Implementierungen zum Auflisten) müssen Sie sich immer noch mit herstellerspezifischen Implementierungen herumschlagen. Das heißt: Nicht alle Anbieter erlauben die Anpassung all dieser Optionen, und es gibt überhaupt keine Standardbenennungskonvention für Kollatierungen. Außerdem sehen nicht alle Anbieter die Sortieroptionen als Teil der Sortierung an: PostgreSQL-Sortierungen sind die Standardreihenfolge für das ausgewählte Gebietsschema und müssen verwendet werden ILIKE, um einen Vergleich ohne Berücksichtigung der Groß- und Kleinschreibung durchzuführen. Nachfolgend finden Sie herstellerspezifische Informationen.
SQL Server (Microsoft)
Die Unterscheidung zwischen dem, was Sie auf diesen beiden MSDN-Dokumentationsseiten sehen, und der von @MartinSmith in einem Kommentar zur Frage bereitgestellten Abfrage (unten leicht überarbeitet):
SELECT *
FROM sys.fn_helpcollations()
WHERE [name] LIKE '%[_]CS[_]AI%';
ist, dass diese beiden MSDN-Seiten speziell auf die sehr veralteten SQL Server-Kollatierungen verweisen, während die Kollatierungen, die als Ergebnis dieser Abfrage angezeigt werden (888 davon ab SQL Server 2012, SP3), Windows-Kollatierungen sind.
Ab SQL Server 2000 sind die älteren SQL Server-Kollatierungen (die erstellt wurden, bevor SQL Server auf die Windows-Kollatierungen zugreifen konnte) veraltet und werden nicht mit neuen Regeln oder Funktionen aktualisiert. Beispielsweise wurde ab SQL Server 2012 eine Reihe von Kollatierungen hinzugefügt, die die ordnungsgemäße Behandlung der integrierten Funktionen für Zusatzzeichen unterstützen (dh die verbleibenden UTF-16-Zeichen jenseits der in UCS-2 ursprünglich definierten "Basis" -65.536-Zeichen) ). Diese neueren Collations Ende in _SC(wie in S upplementary C haracters).
Verwenden Sie am besten keine SQL Server-Kollatierungen, deren Namen mit "" beginnen SQL_. Daher haben Sie Zugriff auf zahlreiche Kollatierungen, die die gesuchte Kombination von Optionen unterstützen (dh Groß- und Kleinschreibung und Akzentunabhängigkeit). Wann immer verfügbar, ist es auch am besten, das eine Ende zu verwenden, _SCsofern alle anderen gewünschten Optionen vorhanden sind.
Während SQL Server die _CS_AINamenskonvention verwendet, gibt es keine Liste aller 3810 (ab SQL Server 2012) Windows-Kollatierungen. Es gibt nur die Seite Name der Windows-Sortierung , auf der alle Gebietsschemas und Versionen aufgelistet sind und wie die Namenskonvention funktioniert, aber das war's.
SQL Server unterstützt auch das Umschalten von Breite und Kana-Empfindlichkeit.
MySQL (von Oracle gekauft)
Die MySQL - Version 5.7, Dokumentation besagt , dass es das nicht unterstützt _ai, _as, _ci, und _csSuffixen (und _binauf Vollständigkeit), sondern auch erklärt:
Bei nichtbinären Kollatierungsnamen, die keine Akzentempfindlichkeit angeben, wird die Groß- und Kleinschreibung berücksichtigt. Das heißt, wenn ein Kollatierungsname nicht _aioder enthält _as, _ciimpliziert dies im Namen _aiund impliziert dies _csim Namen _as.
Ist zum Beispiel latin1_general_cicase insensitiv (und accent insensitiv, implizit), latin1_general_csist case sensitiv (und accent sensitiv, implizit)
Dies impliziert sicherlich, dass es möglich ist, eine latin1_general_cs_aiKollation zu erstellen. Die MySQL Widget 5.5.50 Server jedoch , dass ich Zugang haben keine Sortierungen mit mehr als einem Suffix, und die nur Suffixe ich sehe , sind: _cs, _ciund _binüber 198 insgesamt Sortierungen. Ich habe die SHOW COLLATION verwendet Befehl um sie .
Obwohl MySQL anscheinend eine ähnliche Namenskonvention verwendet (zumindest was diese beiden Optionen betrifft), kann ich keine Sortierung finden, die Ihren Anforderungen entspricht. Es könnte jedoch möglich sein, die Akzente (und andere diakritische Zeichen) zu _csentfernen und eine Kollatierung zu verwenden, um das zu erhalten, was Sie möchten (ähnlich wie Sie es in PostgreSQL tun würden - siehe unten). Ich bin mir dieser Option jedoch nicht sicher und habe im Moment keine Zeit, um weiter zu recherchieren.
ODER Sie könnten Ihre eigene Sammlung erstellen, um genau das zu tun, was Sie wollen. Im Gegensatz zu den anderen RDBMS scheint es mit MySQL ziemlich einfach zu sein, eigene Kollatierungen hinzuzufügen. In diesem Fall haben Sie die volle Kontrolle über die Gewichtung der einzelnen Zeichen. Weitere Informationen finden Sie unter Hinzufügen einer einfachen Sortierung zu einem 8-Bit-Zeichensatz und Hinzufügen einer UCA-Sortierung zu einem Unicode-Zeichensatz .
Weitere Informationen darüber, wie MySQL mit verschiedenen Arten von Kollatierungen umgeht, finden Sie auf der Seite Kollatierungsimplementierungstypen .
PostgreSQL
Kollatierungen in PostgreSQL scheinen weitaus weniger flexibel zu sein. Sie legen fest , nur die Kultur / locale: en_US, de_DEetc. finden Sie unter ihre Dokumentationsseite für Sortierungs Unterstützung für weitere Einzelheiten. Daher erhalten Sie standardmäßig die kulturspezifischen Überschreibungen, aber die Kollatierungen sind ansonsten alles-sensitiv (was übrigens nicht mit einer "binären" Kollatierung identisch ist).
Sie können ILIKE (Abschnitt 9.7.1) verwenden, um die Groß- und Kleinschreibung zu ignorieren, sie haben jedoch keinen ähnlichen Operator für die Akzentempfindlichkeit. Ich habe jedoch festgestellt, dass sie eine Unakzentfunktion haben , mit der Akzente und andere diakritische Zeichen entfernt werden können. Bitte beachten Sie, dass diese Funktion ein zusätzliches mitgeliefertes Modul ist und daher nicht unbedingt auf einem bestimmten PostgreSQL-Server vorhanden ist. Die zuletzt verlinkte Dokumentation besagt:
Wenn von der Quelle Verteilung Aufbau werden diese Komponenten nicht automatisch erstellt, wenn Sie das „Welt“ Ziel bauen
...
Wenn Sie eine abgepackte Version von PostgreSQL verwenden, werden diese Module typischerweise als separate subpackage zur Verfügung gestellt, wie zum Beispiel postgresql-contrib.
In dieser Dokumentation finden Sie Anweisungen, wie Sie diese Funktion erhalten, wenn Sie sie nicht haben und möchten.
Weitere Informationen finden Sie auch in der folgenden Antwort zum Stapelüberlauf:
Unterstützt PostgreSQL "akzentunempfindliche" Kollatierungen?
DB2 (IBM)
Ähnlich wie bei Microsoft SQL Server gibt es bei DB2 zwei Arten von Kollatierungen:
„SYSTEM“ Sortierungen, das folgende Format angegeben werden mit: SYSTEM_{codepage}_[optional-territory]. Diese sind nicht sehr flexibel und scheinen die Anpassung der Empfindlichkeit an Groß- und Kleinschreibung, Akzente oder ähnliches nicht zu unterstützen. Die Liste der unterstützten Sortierungen finden Sie hier: Unterstützte Gebietscodes und Codeseiten
Unicode Collation Algorithm (UCA) -basierte Kollatierungen. Diese unterstützen einiges an Schneiderei. Weitere Informationen zum Konfigurieren des Verhaltens, der Namenskonvention und der Liste der gültigen Gebietsschemas finden Sie auf der Seite mit den auf dem Unicode-Kollatierungsalgorithmus basierenden Kollatierungen. Bitte beachten Sie, dass in Tabelle 1 das Beispiel in der dritten Zeile ("Case Level") mit Folgendem beginnt:
Wenn Sie das Attribut "Groß- / Kleinschreibung" auf "Ein" und das Attribut "Stärke" auf "Primärebene" setzen, wird der Akzent ignoriert, die Groß- / Kleinschreibung jedoch nicht.
Genau das haben Sie gesucht. Aber die Syntax für das heißt:
CLDR181_EO_S1. Aus diesem Grund haben Sie bei Ihrer Suche keine Informationen zu DB2 gefunden.
Orakel
Oracle 10g fügte Unterstützung für akzentunabhängige Vergleiche und Sortierungen hinzu. Jedoch:
- Sie haben nur die Möglichkeit, "unempfindliche" Operationen zu kennzeichnen:
_CIund_AI
- Sie können jeweils nur eine dieser Optionen angeben
- die Option ohne Berücksichtigung der Groß- / Kleinschreibung -
_CI - ohne ist immer noch akzentabhängig
- die akzentunabhängige Option -
_AI- "ist immer auch unabhängig von Groß- und Kleinschreibung." (Zitiert aus der Dokumentation, die unten verlinkt ist)
Bitte beachten Sie deren linguistische Sortierung und String-Suche Dokumentationsseite für weitere Informationen und Beispiele.
SAP ASE (ehemals Sybase ASE, auch bekannt als Sybase)
ASE unterstützt eine oder mehrere der folgenden Kombinationen von Empfindlichkeiten pro Gebietsschema / Zeichensatz:
- Groß- und Kleinschreibung, Akzent-sensitive
- Groß- / Kleinschreibung wird nicht berücksichtigt, Akzent wird nicht berücksichtigt
- Groß- und Kleinschreibung, Akzentabhängigkeit, Reihenfolge mit Vorzug
- Groß- / Kleinschreibung wird nicht berücksichtigt, Akzent wird nicht berücksichtigt
Die Beziehung zwischen dem Gebietsschema, dem Zeichensatz und der verfügbaren Sortierreihenfolge finden Sie auf der Seite Standard- Sortierreihenfolge auswählen . Die vollständige Liste der Kollatierungen finden Sie auf der Seite Kollatierungsnamen und -IDs .
Die Namenskonvention für die Sortierung ist insofern willkürlich, als sie alle aus 4 bis 8 Zeichen bestehen und versuchen, den Namen oder die Codepage des Gebietsschemas und einen gewissen Sinn für die Sortierung zu erfassen. Beispielsweise:
altnoacc== "CP 850 Alternative - ohne Akzent"
rusdict== "Russische Wörterbuchbestellung"
dynix == "Chinesische phonetische Reihenfolge"
Auf der Seite Auswählen der Standard-Unicode-Sortierreihenfolge wird ein Hinweis angezeigt :
Sie können Sortierreihenfolgen mithilfe von externen Dateien in hinzufügen $/collate/Unicode Verzeichnis . Die Namen und Kollatierungs-IDs werden in gespeichert syscharsets. Die Namen der externen Unicode-Sortierreihenfolgen müssen nicht eingegeben werden, syscharsetsbevor Sie die Standard-Unicode-Sortierreihenfolge festlegen können.
...
Externe Unicode-Sortierreihenfolgen werden von SAP bereitgestellt. Versuchen Sie nicht, externe Unicode-Sortierreihenfolgen zu erstellen.
Es ist unklar, ob SAP eine externe Sortierreihenfolge bereitstellen würde, um Groß- und Kleinschreibung zu berücksichtigen Kleinschreibung Akzentunabhängigkeit zu berücksichtigen. Vielleicht schicke ich ihnen eines Tages eine E-Mail und frage, ob eine angefordert werden könnte.
Um die gewünschte Kombination von Empfindlichkeiten zu erhalten, sollten Sie in der Lage sein, eine skalare benutzerdefinierte Funktion zum Entfernen von Akzenten und anderen diakritischen Zeichen zu erstellen .
Informix (von IBM gekauft)
Informix scheint meist nur das Standardsortier- und -vergleichsverhalten einer Kollatierung zu unterstützen. Daher sind Kollatierungen nur das Gebietsschema und der Zeichensatz. Groß- und Kleinschreibung wird auf Datenbankebene behandelt. Standardmäßig wird zwischen Groß- und Kleinschreibung unterschieden. Sie können eine Datenbank (nicht eine Tabelle, eine Spalte, eine Abfrage oder sogar ein Prädikat) so festlegen, dass Groß- und Kleinschreibung nicht berücksichtigt wird festlegen nicht berücksichtigt indem Sie NLSCASE INSENSITIVE in der CREATE DATABASEAnweisung angeben .
Obwohl die Datenbanksortierung (Gebietsschema und Zeichensatz) pro Clientverbindung überschrieben werden kann, scheint es keine Möglichkeit zu geben, die Einstellung für die Groß- und Kleinschreibung zu überschreiben. UND, die NLSCASEOption hat aus einem Grund "NLS" im Namen: Sie wirkt sich nur auf NCHARund ausNVARCHAR Daten aus; CHARund VARCHARsind immer Groß- und Kleinschreibung.
Die Akzentempfindlichkeit wird nicht angesprochen, und es gibt keine integrierte Funktion zum Entfernen der Akzente / diakritischen Markierungen.
Die Namenskonvention für Informix Collation lautet:
<lang>_<country>.<code set>
woher:
<lang> = ein 2-Buchstaben- oder 3-Buchstaben-Sprachcode<country> = ein 2-stelliger Länder- oder Regionscode<code set> = die Codepage, die auf eine der 3 folgenden äquivalenten Arten angegeben wurde:
- Name: 8859-1
- Dezimalwert der IBM CCSID-Nummer: 819
- Hexadezimalwert der IBM CCSID-Nummer: 0333
Daher beziehen sich die folgenden drei Gebietsschemaspezifikationen alle auf genau dasselbe Gebietsschema:
- fr_fr.8859-1
- fr_fr.819
- fr_fr.0333
Weitere Informationen finden Sie unter: