Logo faq-o-matic.net
Logo faq-o-matic.net

SQL Server: Sortierung als Stolperfalle

von veröffentlicht am26. September 2011, 06:10 Uhr Kurzlink und Zitatlink einblenden
Kategorie Kategorie: SQL Server   Translate with Google Translate Translate EN   Die angezeigte Seite drucken

Eine Eigenschaft des SQL Server ist weitgehend unbekannt, kann aber in speziellen Situationen zu unerwarteten Ergebnissen führen: Die Sortierreihenfolge (“Collation”) von Tabellendaten. Anders als der Name erwarten lässt, beeinflusst diese Einstellung nicht nur die Abfolge, in der angefragte Daten vom Server zurückgegeben werden, sondern auch, welche Werte SQL Server überhaupt ausgibt. Hierunter fällt z.B. die Frage, ob SQL Server die Groß- und Kleinschreibung von Textdaten unterscheidet oder nicht.

In früheren Versionen der Software konnte man die Sortierreihenfolge nur auf der Serverebene festlegen – sie galt damit für alle Datenbanken und alle Tabellen einheitlich, die auf dem Server abgelegt waren. Zusätzlich entschied diese Einstellung darüber, welche Datenbanken man überhaupt auf dem Server betreiben konnte: Hatte man eine Datenbank auf einem Server mit Sortierung A eingerichtet, konnte es passieren, dass man diese auf einem anderen Server mit Sortierung B nicht einsetzen konnte.

In aktuellen Versionen unterstützt SQL Server unterschiedliche Sortierreihenfolgen auf verschiedenen Ebenen. Die Einstellung auf Serverebene (die man direkt bei der Installation festlegt!) gibt für die Systemdatenbanken (insbesondere “master” und “msdb”) sowie als Vorgabe für alle neuen Datenbanken. Legt man Datenbanken an, kann man dort eine eigene (auch abweichende) Sortierreihenfolge definieren. Und schließlich darf man mittlerweile auch für einzelne Tabellenspalten die Sortierreihenfolge auswählen.

image

Auswahl der Sortierreihenfolge für eine neue Datenbank. Diese Festlegung kann man später nicht ändern!

Im Installationsumfang von SQL Server finden sich hunderte Sortierreihenfolgen für verschiedene Sprachen. Sie unterscheiden sich nach dem Grundprinzip, ob sie Zeichen binär (nach ihrem Zeichencode) oder lexikalisch (also in alphabetisch korrekter Folge) interpretieren, daneben aber vor allem in der Unterscheidung von Groß- und Kleinschreibung, von Akzenten oder weiteren sprachlichen Eigenschaften. Eine Idee davon vermittelt das folgende Dialogfeld, das die Auswahl ermöglicht:

image

Sortieroptionen für eine einzelne Spalte

Ein Beispiel soll die Auswirkungen verschiedener Sortierreihenfolge auf die Daten verdeutlichen, die SQL Server auf eine Abfrage zurückgibt. Betrachten wir eine simple Tabelle mit zwei Textspalten. Für die erste Spalte “WertCS” gibt eine Sortierung mit Unterscheidung nach Groß-/Kleinschreibung (“Case Sensitive”) sowie nach Akzent (“Accent Sensitive”). In der zweiten Spalte “WertCI” gilt keine Unterscheidung dieser beiden Kriterien. (Anmerkung: Dies weicht von der Standardeinstellung ab, die SQL Server von sich aus vorschlägt: Dort gilt keine Unterscheidung nach Groß-/Kleinschreibung (“Case Insensitive”), Akzente werden aber unterschieden (“Accent Sensitive”).

In beide Spalten tragen wir nun Werte ein. Damit man die Auswirkungen sieht, stehen in jeder Spalte Wertpaare: Derselbe Wert einmal mit und ohne Großbuchstaben sowie derselbe Eintrag mit und ohne Akzent.

image

Daten in der Testtabelle

Nun folgen ein paar Abfragen. Die Komplettabfrage gibt natürlich die ganze Tabelle aus:

SELECT * FROM WerteCSCI

image

Abfrage der ganzen Tabelle

Die zweite Abfrage sucht einen Wert und gibt diesen nur mit Kleinbuchstaben an. Das Ergebnis der ersten Spalte (“Case Sensitive”):

SELECT WertCS FROM WerteCSCI WHERE WertCS = 'hurz'

image

Abfrage der Case-Sensitive-Spalte

Und das Ergebnis für die zweite Spalte (“Case Insensitive”):

SELECT WertCI FROM WerteCSCI WHERE WertCI = 'hurz'

image

Abfrage der Case-Insensitive-Spalte

Der Unterschied ist deutlich sichtbar. Bei einer Sortierreihenfolge ohne Unterscheidung nach Groß- und Kleinschreibung (dies ist der Standard, wenn man die Definition nicht ausdrücklich ändert) gibt SQL Server die Daten unabhängig von der Schreibung zurück. Das ist in den meisten Situationen das erwartete Verhalten.

Dasselbe Phänomen zeigt sich auch bei den Akzenten. Hier allerdings ist die Installationsvorgabe anders: Standardmäßig unterscheidet SQL Server nach der Akzentuierung. In diesem Fall entspricht also das erste Beispiel dem “normalen” Verhalten.

SELECT WertCS FROM WerteCSCI WHERE WertCS = 'baba'

image

Abfrage der Accent-Sensitive-Spalte

Und das Ergebnis für die zweite Spalte (“Case Insensitive”):

SELECT WertCI FROM WerteCSCI WHERE WertCI = 'baba'

image

Abfrage der Accent-Insensitive-Spalte

© 2005-2019 bei faq-o-matic.net. Alle Rechte an den Texten liegen bei deren Autorinnen und Autoren.

Jede Wiederveröffentlichung der Texte oder von Auszügen daraus - egal ob kommerziell oder nicht - bedarf der ausdrücklichen Genehmigung durch die jeweiligen Urheberinnen oder Urheber.

Das Impressum findet sich unter: http://www.faq-o-matic.net/impressum/

Danke, dass du faq-o-matic.net nutzt. Du hast ein einfaches Blog sehr glücklich gemacht!