Sortierungsterminologie

Zur optimalen Verwendung der Sprachunterstützung in SQL Server 2005 ist es erforderlich, die in diesem Thema beschriebenen Begriffe zu verstehen.

Begriffe

  • Codepage
  • Sortierung
  • Datentyp
  • Globalisierung
  • Gebietsschema
  • Leserichtung
  • Sortierreihenfolge
  • Unicode

Codepage

Eine Codepage ist ein geordneter Satz von Zeichen in einem vorgegebenen Skript, in dem ein numerischer Index, oder Codepunktwert, mit jedem Zeichen verbunden ist. Eine Codepage in Microsoft Windows wird meist als Zeichensatz oder charset bezeichnet. Codepages werden zur Unterstützung der Zeichensätze und Tastaturlayouts verschiedener Windows-Gebietsschemas verwendet.

Verwandte Themen:Festlegen von Clientcodepages

Zurück zum Anfang

Sortierung

Eine Sortierung gibt die Bitmuster an, die die jeweiligen Zeichen in einem Datensatz darstellen. Sortierungen bestimmen auch die Regeln zum Sortieren und Vergleichen von Daten. SQL Server 2005 unterstützt das Speichern von Objekten mit verschiedenen Sortierungen in einer Datenbank. Jede Spalte in einer SQL Server-Datenbank kann eine eigene Sortierung besitzen. Bei Nicht-Unicode-Spalten gibt die Sortierungseinstellung die Codepage für die Daten und, als Ergebnis, die Zeichen an, die dargestellt werden können. Daten können nahtlos zwischen Unicode-Spalten verschoben werden. Zwischen Nicht-Unicode-Spalten ist ein nahtloses Verschieben von Daten nicht möglich, da die Daten von der aktuellen Codepage konvertiert werden müssen.

Das Ergebnis einer Transact-SQL-Anweisung kann abweichen, wenn die Anweisung im Kontext verschiedener Datenbanken ausgeführt wird, die jeweils eine andere Sortierungseinstellung haben. Als bewährte Methode sollte in Unternehmen eine standardisierte Sortierung verwendet werden. Wenn Sie unternehmensweit standardisierte Sortierungseinstellungen verwenden, müssen Sie die für einzelne Zeichenfolgen- oder Unicode-Ausdrücke verwendeten Sortierungen nicht mehr explizit festlegen. Bei Objekten mit abweichenden Sortierungs- oder Codepageeinstellungen müssen Sie die Abfragen so codieren, dass diese den Regeln der Sortierungspriorität entsprechen. Weitere Informationen finden Sie im Abschnitt zur Rangfolge der Sortierungen (Transact-SQL).

Die Merkmale einer Sortierung sind abhängig von Sprache, Groß-/Kleinschreibung, Akzent, Kana und Breite.

SQL Server 2005-Sortierungen beinhalten die folgenden Gruppierungen:

  • Windows-Sortierungen
    Windows-Sortierungen definieren Regeln zum Speichern von Zeichendaten basierend auf dem zugehörigen Gebietsschema von Windows. Bei einer Windows-Sortierung verwendet der implementierte Vergleich von Nicht-Unicode-Daten denselben Algorithmus wie bei Unicode-Daten. Die grundlegenden Windows-Sortierungsregeln geben an, welches Alphabet oder welche Sprache verwendet wird, wenn Wörterbuchsortierung angewendet wird. Zudem geben die Regeln die Codepage an, die zum Speichern von Nicht-Unicode-Zeichendaten verwendet wird. Sowohl die Unicode- als auch die Nicht-Unicode-Sortierung sind kompatibel mit Zeichenfolgenvergleichen in einer bestimmten Version von Windows. Dies gewährt eine datentypübergreifende Konsistenz innerhalb von SQL Server und bietet Entwicklern außerdem die Möglichkeit, Zeichenfolgen in ihren Anwendungen mithilfe derselben Regeln zu sortieren, die auch von SQL Server verwendet werden (durch Aufrufen der CompareStringW-Funktion der Microsoft Win32-API). Weitere Informationen finden Sie unter Sortierungseinstellungen im Setup-Programm.
  • Binäre Sortierungen
    Binäre Sortierungen sortieren Daten basierend auf der Sequenz codierter Werte, die durch das Gebietsschema und den Datentyp definiert sind. Eine binäre Sortierung in SQL Server definiert das zu verwendende Sprachgebietsschema sowie die zu verwendende ANSI-Codepage und erzwingt eine binäre Sortierreihenfolge. Binäre Sortierungen helfen aufgrund ihrer relativen Einfachheit beim Erreichen einer verbesserten Anwendungsleistung. Bei Nicht-Unicode-Datentypen basieren Datenvergleiche auf den in der ANSI-Codepage definierten Codepunkten. Bei Unicode-Dateitypen basieren Datenvergleiche auf den Unicode-Codepunkten. Bei binären Sortierungen von Unicode-Datentypen wird das Gebietsschema bei Datensortierungen nicht berücksichtigt. Beispielsweise führen Latin_1_General_BIN und Japanese_BIN bei Unicode-Daten zu den gleichen Sortierergebnissen.

    Frühere binäre Sortierungen in SQL Server führten für Unicode-Daten einen unvollständigen Codepunkt-zu-Codepunkt-Vergleich aus. Bei diesen älteren binären Sortierungen von SQL Server wurde das erste Zeichen als WCHAR verglichen, gefolgt von einem byteweisen Vergleich. Aus Gründen der Abwärtskompatibilität wird die Semantik vorhandener binärer Sortierungen nicht geändert.

    Binäre Sortierungen in dieser Version von SQL Server beinhalten einen neuen Satz von Sortierungen, die auf reinen Codepunktvergleichen basieren. Die Kunden können auf die neuen binären Sortierungen umsteigen, um vom Vorteil echter Codepunktvergleiche Gebrauch zu machen. Zur Entwicklung neuer Anwendungen sollten Sie die neuen binären Sortierungen einsetzen. Der neue BIN2-Suffix identifiziert die Namen von Sortierungen, die die neue auf Codepunkten basierende Sortierungssemantik implementieren. Außerdem wird ein neuer Vergleichsflag hinzugefügt, der dem Suffix BIN2 für die neue binäre Sortierung entspricht. Weitere Informationen finden Sie unter Verwenden binärer Sortierungen.

  • SQL Server-Sortierungen
    Die Sortierreihenfolge von SQL Server-Sortierungen ist kompatibel mit der früherer Versionen von SQL Server. SQL Server-Sortierungen basieren auf SQL Server-Legacy-Sortierreihenfolgen für Nicht-Unicode-Daten, z. B. den Datentypen char und varchar, die durch SQL Server definiert sind. Die Wörterbuch-Sortierungsregeln für Nicht-Unicode-Daten sind nicht kompatibel mit den durch das Betriebssystem Windows bereitgestellten Sortierroutinen. Das Sortieren von Unicode-Daten ist aber kompatibel mit einer bestimmten Version der Windows-Sortierungsregeln. Da SQL Server-Sortierungen unterschiedliche Vergleichsregeln für Nicht-Unicode- und Unicode-Daten verwenden, werden bei Vergleichen derselben Daten in Abhängigkeit von dem zugrunde liegenden Datentyp möglicherweise unterschiedliche Ergebnisse angezeigt. Weitere Informationen finden Sie unter Verwenden von SQL-Sortierungen.

    ms143726.note(de-de,SQL.90).gifHinweis:
    Wenn Sie eine Instanz von SQL Server aktualisieren, können Sie SQL Server-Sortierungen angeben, die mit vorhandenen Instanzen von SQL Server kompatibel sein sollen. Da die Standardsortierung einer Instanz von SQL Server während des Setups festgelegt wird, ist es wichtig, die Sortierungseinstellungen in den folgenden Fällen sorgfältig anzugeben:
    • Ihr Anwendungscode ist abhängig vom Verhalten früherer SQL Server-Sortierungen.
    • Sie beabsichtigen, die SQL Server 2005-Replikation mit vorhandenen Installationen von SQL Server 6.5 oder SQL Server 7.0 zu verwenden.
    • Sie müssen Zeichendaten speichern, die mehrere Sprachen wiedergeben.

SQL Server 2005 unterstützt das Festlegen von Sortierungen auf den folgenden Ebenen einer SQL Server 2005-Instanz:

  • Sortierungen auf Serverebene
    Die Standardsortierung einer SQL Server-Instanz wird während des Setups festgelegt. Die Standardsortierung der Instanz wird auch die Standardsortierung der Systemdatenbanken: master, model, tempdb, msdb und distribution. Mit Ausnahme der Sortierung von Spalten und Datenbanken kann die Sortierung, die einem Objekt zugewiesen wurde, nur durch Löschen und erneutes Erstellen des Objekts geändert werden. Statt die Standardsortierung einer SQL Server-Instanz zu ändern, können Sie die Sortierung auch beim Erstellen einer neuen Datenbank oder einer Datenbankspalte angeben.

    Zum Abfragen der Serversortierung einer SQL Server-Instanz verwenden Sie die folgende SERVERPROPERTY-Transact-SQL-Funktion:

    SELECT CONVERT (varchar, SERVERPROPERTY('collation'))
    

    Verwenden Sie die folgende integrierte fn_helpcollations()-Funktion, um alle verfügbaren Sortierungen vom Server abzufragen.

    SELECT * from ::fn_helpcollations()
    
  • Sortierungen auf Datenbankebene
    Nachdem eine Datenbank erstellt wurde, kann mithilfe der COLLATE-Klausel der CREATE DATABASE-Anweisung die Standardsortierung der Datenbank angegeben werden. Wenn beim Erstellen einer Datenbank keine Sortierung angegeben wurde, wird der Datenbank die Standardsortierung der model-Datenbank zugewiesen. Die Standardsortierung der model-Datenbank entspricht der Standardsortierung der SQL Server-Instanz.

    Die Sortierung einer Benutzerdatenbank kann folgendermaßen mithilfe einer ALTER DATABASE-Anweisung geändert werden:

    ALTER DATABASE myDB COLLATE Greek_CS_AI
    

    Die aktuelle Sortierung einer Datenbank kann mithilfe der folgenden Anweisung abgerufen werden:

    SELECT CONVERT (varchar, DATABASEPROPERTYEX('database_name','collation'))
    
    ms143726.note(de-de,SQL.90).gifHinweis:
    Das Ändern der Sortierung auf Datenbankebene hat keinen Einfluss auf Sortierungen auf Benutzer-, Tabellen- und Spaltenebene.
  • Sortierungen auf Spaltenebene
    Beim Erstellen einer Tabelle kann mithilfe der COLLATE-Klausel der CREATE TABLE-Anweisung für jede Zeichenfolgenspalte eine Sortierung angeben werden. Wenn beim Erstellen einer Tabelle keine Sortierung angegeben wurde, wird der Spalte die Standardsortierung der Datenbank zugewiesen.

    Die Sortierung einer Spalte kann folgendermaßen mithilfe der ALTER TABLE-Anweisung geändert werden:

    ALTER TABLE myTable ALTER COLUMN mycol NVARCHAR(10) COLLATE Greek_CS_AI
    
  • Sortierungen auf Ausdrucksebene
    Sortierungen auf Ausdrucksebene werden zum Zeitpunkt der Ausführung einer Anweisung festgelegt. Sie haben Auswirkungen auf die Art und Weise, wie ein Resultset zurückgegeben wird. Auf diese Weise kann ein Ergebnis sortiert und somit die ORDER BY-Klausel sprachspezifisch verwendet werden. Implementieren Sie mithilfe einer COLLATE-Klausel folgendermaßen Sortierungen auf Ausdrucksebene:

    SELECT name FROM customer ORDER BY name COLLATE Latin1_General_CS_AI
    

Zurück zum Anfang

Datentyp

Datentyp ist eine Definition, die einen Wertebereich, die Vorgänge, die mit den Werten ausgeführt werden können, und die Art und Weise, in der die Werte im Arbeitsspeicher des Computers gespeichert werden, angibt. Das Definieren von Datentypen ermöglicht es SQL Server, Daten auf vorhersehbare Weise zu manipulieren. Nicht-Unicode-Zeichendatentypen sind char, varchar und text. Unicode-Datentypen verwenden die Unicode-Zeichendarstellung. Zu den Unicode-Datentypen gehören nchar, nvarchar und ntext. Sie sollten in Ihren Anwendungen den Unicode-Datentypen den Vorzug geben, besonders wenn Sie Zeichendaten speichern, die mehrere Sprachen wiedergeben.

Verwandte Themen:Datentypen (Datenbankmodul), Datentypen (Transact-SQL), SQL Server Integration Services-Datentypen

Zurück zum Anfang

Globalisierung

Globalisierung bezeichnet den Prozess der Entwicklung einer Softwareanwendung, bei der Features und Codeentwurf mehrere gesprochene Sprachen und Gebietsschemas berücksichtigen. Ein globalisierter Anwendungsentwurf umfasst mehrere Gebietsschemas und Sprachen mit Unicode-Unterstützung für die Eingabe, Verarbeitung, Anzeige und Ausgabe von Daten.

Verwandte Themen:Internationale Überlegungen für SQL Server

Zurück zum Anfang

Gebietsschema

Ein Gebietsschema ist ein Satz von Informationen, die einem Ort oder einer Kultur zugeordnet sind: der Name und Bezeichner der gesprochenen Sprache, die Schrift, die zum Schreiben dieser Sprache verwendet wird, sowie kulturelle Konventionen. SQL Server 2005 unterstützt alle 135 Gebietsschemas, die von Windows XP unterstützt werden. Dazu zählen die fünf chinesischen Sprachgebietsschemas (Hongkong (SAR), Macau (SAR), Volksrepublik China, Singapur und Taiwan); dreizehn englische Sprachgebietsschemas (Australien, Belize, Kanada, Karibik, Irland, Jamaika, Neuseeland, Philippinen, Südafrika, Trinidad, Großbritannien, USA und Simbabwe) sowie sechs französische Sprachgebietsschemas (Belgien, Kanada, Frankreich, Luxemburg, Monaco und Schweiz).

Die folgende Tabelle veranschaulicht einige Unterschiede zwischen vier häufig verwendeten von Windows unterstützten Gebietsschemas.

Gebietsschema Englisch (USA) Französisch (Frankreich) Japanisch Vereinigte Arabische Emirate

Land/Region

USA

Frankreich

Japan

Vereinigte Arabische Emirate

Sprache

Englisch

Französisch

Japanisch

Arabisch

Schrift

Latein

Latein

Kana, Kanji

Arabisch

Leserichtung

Von links nach rechts

Von links nach rechts

Von links nach rechts

Von rechts nach links

Durch Windows definierte Codepage

1252

1252

932

1256

Zeitformat

1:00 pm

13:00

13:00

1:00 p

Kalender

Gregorianisch

Gregorianisch

Gregorianisch (lokal angepasst)

Gregorianisch (lokal angepasst)

Standardpapierformat

US-Letter

A4

A4

A4

Dezimaltrennzeichen

.

,

.

,

Listentrennzeichen

,

;

,

;

Tausendertrennzeichen

,

Leerzeichen

,

,

Zurück zum Anfang

Leserichtung

Die Leserichtung ist die generelle Richtung einer geordneten Textsequenz in Bezug auf die Wortreihenfolge (nicht in Bezug auf die Reihenfolge der eingegebenen Zeichen). Bei der Verwendung von Arabisch als Tastatursprache werden neue Zeichen beispielsweise von rechts nach links eingegeben. Bei Latein als Tastatursprache erfolgt die Eingabe von links nach rechts.

Zurück zum Anfang

Sortierreihenfolge

Die Sortierreihenfolge gibt an, wie Datenwerte sortiert werden und hat so Einfluss auf die Ergebnisse von Datenvergleichen. Das Sortieren von Daten wird über Sortierungen erreicht und kann mithilfe von Indizes optimiert werden.

Verwandte Themen:Sortierarten für Windows-Sortierung, Indizes

Zurück zum Anfang

Unicode

Unicode stellt die Zeichen einer Sprache statt mit einem Byte mit zwei Bytes dar. Auf diese Weise kann ein einzelner Unicode-Zeichensatz fast alle auf der Welt gesprochenen Sprachen darstellen. Unicode wurde vom Unicode Consortium, einer gemeinnützigen Organisation der Computerindustrie, entwickelt und wird weiterhin von ihr betreut. Weitere Informationen finden Sie auf der Website des Unicode Consortium.

Wenn Sie Zeichendaten speichern, die mehrere Sprachen darstellen, müssen Sie statt der Nicht-Unicode-Datentypen (char, varchar und text) die Unicode-Datentypen (nchar, nvarchar und ntext) verwenden. Die Verwendung von Unicode kann zu einer merklichen Leistungssteigerung führen, da weniger Codepagekonvertierungen erforderlich sind. Nicht-Unicode-Datentypen sind mit erheblichen Beschränkungen verbunden, da ein Nicht-Unicode-Computer auf die Verwendung einer einzelnen Codepage beschränkt ist. Zum umfassenden Abwägen des Für und Widers von Unicode- und Nicht-Unicode-Datentypen müssen Sie Ihr Szenario testen und die Leistungsunterschiede zwischen den Umgebungen messen. Sie sollten zumindest die Sitesortierung standardisieren und so weit wie möglich Unicode-Server und -Clients bereitstellen.

In den meisten Fällen wird Ihre SQL Server-Instanz mit anderen Servern oder Clients interagieren und möglicherweise mehrere Standards für den Datenzugriff verwenden. SQL Server-Clients sind von einem der beiden Haupttypen:

  • Unicode-Clients, die OLE DB und Open Database Connectivity (ODBC), Version 3.7 oder höher, verwenden.
  • Nicht-Unicode-Clients, die DB Library und ODBC, Version 3.6 oder höher, verwenden.

Die folgende Tabelle veranschaulicht zu beachtende Aspekte bei der Verwendung mehrsprachiger Daten mit verschiedenen Kombinationen von Unicode- und Nicht-Unicode-Servern.

Server Client Vorteile oder Beschränkungen

Unicode

Unicode

Eine ideale Konfiguration, da im gesamten System Unicode-Daten verwendet werden. Dieses Szenario bietet die beste Leistung und Schutz vor der Beschädigung abgerufener Daten. Dies ist der Fall bei Microsoft ActiveX Data Objects (ADO), OLE DB und ODBC, Version 3.7 oder höher.

Unicode

Nicht-Unicode

In diesem Szenario ist die Datenspeicherung wahrscheinlich unproblematisch. Beschränkungen können jedoch beim Verschieben der Daten auf einen Clientcomputer auftreten. Zumindest müssen die Unicode-Daten mithilfe der Codepage auf dem Nicht-Unicode-Client konvertiert werden.

Nicht-Unicode

Unicode

Dies ist keine günstige Konfiguration bei der Verwendung mehrsprachiger Daten Sie sind nicht in der Lage, Unicode-Daten auf den Nicht-Unicode-Server zu schreiben. Es ist wahrscheinlich, dass Probleme auftreten, wenn Daten an Server gesendet werden, die von der Codepage des Servers nicht erfasst werden.

Nicht-Unicode

Nicht-Unicode

Dieses Szenario ist bei mehrsprachigen Daten mit zahlreichen Beschränkungen verbunden. Sie sind auf die Verwendung einer einzelnen Codepage beschränkt. Die ideale Konfiguration besteht aus einem Unicode-Server und Unicode-Clients.

Verwandte Themen:Grundlagen zu Unicode

Zurück zum Anfang

Siehe auch

Verweis

Sortierungsoptionen und internationale Unterstützung

Hilfe und Informationen

Informationsquellen für SQL Server 2005