Wann müssen wir NVARCHAR / NCHAR statt VARCHAR / CHAR in SQL Server verwenden?

https://stackoverflow.com/questions/612430

03-07-2019
|

Frage

Gibt es eine Regel, wenn wir die Unicode-Typen verwenden müssen?

Ich habe gesehen, dass die meisten europäischen Sprachen (Deutsch, Italienisch, Englisch, ...) in der gleichen Datenbank fein sind in VARCHAR-Spalten.

Ich bin auf der Suche nach so etwas wie:

Wenn Sie Chinesen haben -> verwenden NVARCHAR
Wenn Sie Deutsch und Arabisch -> Verwendung NVARCHAR

Was ist mit der Sortierung der Server / Datenbank?

Ich möchte NVARCHAR nicht verwenden immer wie hier vorgeschlagen Was sind die wichtigsten Leistungsunterschiede zwischen varchar und nvarchar SQL Server-Datentypen?

Lösung

Der wahre Grund, warum Sie wollen NVARCHAR verwenden ist, wenn Sie unterschiedliche Sprachen in der gleichen Spalte, müssen Sie die Spalten in T-SQL ohne Dekodierung adressieren, Sie wollen, dass die in der Lage sein zu sehen, Daten "nativ" in SSMS, oder Sie wollen auf Unicode standardisieren.

Wenn Sie die Datenbank als stumm Speicher behandeln, ist es durchaus möglich, Wide-Strings zu speichern und verschiedene (auch mit variabler Länge) Codierungen in VARCHAR (zB UTF-8). Das Problem kommt, wenn Sie zu kodieren und zu dekodieren versuchen, vor allem, wenn die Codepage für verschiedene Zeilen unterschiedlich ist. Es bedeutet auch, dass der SQL Server wird für die Zwecke der Abfrage innerhalb von T-SQL auf (potentiell variabel) codierten Spalten nicht in der Lage sein, leicht mit den Daten befassen.

Mit NVARCHAR vermeidet all dies.

würde ich NVARCHAR für jede Spalte empfehlen, die vom Benutzer eingegebenen Daten darin haben, die relativ ungezwungen ist.

würde ich VARCHAR für jede Spalte empfehlen, die ein natürlicher Schlüssel (wie ein Kfz-Kennzeichen, SSN, Seriennummer, Service-Tag, Auftragsnummer, Flughafen Rufzeichen, etc.) ist die in der Regel definiert und begrenzt durch einen Standard oder Rechtsvorschriften oder Konvention. VARCHAR auch für Benutzer eingegebenen und sehr beschränkt (wie eine Telefonnummer) oder einen Code (ACTIVE / CLOSED, Y / N, M / F, M / S / D / B, etc.). Es gibt absolut keinen Grund, NVARCHAR für diejenigen zu verwenden.

Also für eine einfache Regel:

VARCHAR, wenn garantiert werden eingeschränkt NVARCHAR sonst

Andere Tipps

Sie sollten NVARCHAR jederzeit verwenden Sie mehrere Sprachen zu speichern haben. Ich glaube, dass Sie es für die asiatischen Sprachen verwenden müssen, aber zitieren Sie mich nicht darauf.

Hier ist das Problem, wenn Sie zum Beispiel Russisch nehmen und speichert sie in einer varchar, werden Sie in Ordnung sein, solange Sie die richtige Codepage definieren. Aber lassen Sie sich sagen, dass Ihr ein Standard-Englisch SQL installieren verwendet, dann die russischen Zeichen nicht korrekt behandelt werden. Wenn Sie NVARCHAR wurden () verwenden sie behandelt werden würde richtig.

Bearbeiten

Ok ich zitiere MSDN und maybee Ich war zu spezifische, aber Sie wollen nicht mehr als eine Codepage in einer varcar Spalte speichern, während Sie können, sollten Sie nicht

Wenn Sie mit Textdaten beschäftigen, die ist in der char gespeichert, varchar VARCHAR (max) oder Textdatentyp, der wichtigste Einschränkung zu betrachten ist, dass nur Informationen aus einem einzigen Codepage kann durch die validiert werden System. (Sie können die Speicherung von Daten aus mehrere Codepages, aber dies ist nicht empfohlen.) Die Seite genaue Code verwendet zu validieren und speichern die Daten abhängt auf der Sortierung der Spalte. Wenn ein Spaltenebene Sortierungs war nicht definiert, die Sortierung der Datenbank wird genutzt. Um die Codepage zu bestimmen dass für eine gegebene Spalte verwendet, Sie können die COLLATIONPROPERTY verwenden Funktion, wie im folgenden gezeigt Code-Beispiele:

Hier ist etwas mehr:

Dieses Beispiel zeigt die Tatsache, dass viele Gegenden, wie georgische und Hindi, keinen Code Seiten haben, da sie sind Unicode-only-Sortierungen. Jene Sortierungen sind nicht geeignet für Spalten, die die char, varchar verwenden oder Text-Datentyp

So Georgian oder Hindi wirklich braucht, als nvarchar gespeichert werden. Arabisch ist auch ein Problem:

Ein weiteres Problem auftreten könnte, ist die Unfähigkeit, Daten zu speichern, wenn nicht alle Zeichen, die Sie möchten Unterstützung ist im Code enthaltenen Seite. In vielen Fällen hält Windows- eine bestimmte Codepage ein „Beste zu sein fit“Codepage, was bedeutet, es gibt keine Garantie, dass Sie sich auf die verlassen können Codepage der gesamten Text zu behandeln; es ist nur die beste zur Verfügung. Ein Beispiel hierfür ist die arabische Schrift: sie unterstützt eine Vielzahl von Sprachen, einschließlich Baluchi, Berber, Farsi, Kashmiri, Kasachisch, Kirgisisch, Pashto, Sindhi, Uiguren, Urdu, und vieles mehr. Alle diese Sprachen haben zusätzliche Zeichen über die in der arabischen Sprache wie in Windows-Code definiert Seite 1256. Wenn Sie zu speichern versuchen, diese zusätzlichen Zeichen in einem Nicht-Unicode-Spalte, die die arabische hat Sortierung, die Charaktere sind umgerechnet in Fragezeichen.

Etwas im Auge zu behalten, wenn Sie Unicode verwenden, obwohl Sie verschiedene Sprachen in einer einzigen Spalte speichern können Sie nur eine einzige Art Sortierung verwendet. Es gibt einige Sprachen, die lateinische Zeichen verwenden, aber sortieren nicht wie andere lateinische Sprachen. Akzente ist ein gutes Beispiel dafür, kann ich nicht das Beispiel remeber aber es gab eine osteuropäische Sprache, deren Y nicht wie die Engländer Y. sortieren hat Dann gibt es die spanische ch die spanische Benutzer expet nach h sortiert werden.

Alles in allem mit allen Fragen mit Ihnen zu tun haben, wenn sie mit internalitionalization beschäftigen. Es ist meine Meinung, die einfacher ist, nur Unicode-Zeichen von Anfang an verwenden, um die zusätzliche Umwandlungen zu vermeiden und den Raum Schlag zu nehmen. Daher meine Aussage früher.

Griechisch müßte UTF-8 auf N Spaltentypen: αβγ;)

Josh sagt: “.... Etwas im Auge zu behalten, wenn Sie Unicode verwenden, obwohl Sie verschiedene Sprachen in einer einzigen Spalte speichern können, können Sie nur eine einzige Art Sortierung verwendet wird. Es gibt einige Sprachen, die lateinische Zeichen verwenden, aber sortieren nicht wie andere lateinische Sprachen . Akzente ein gutes Beispiel dafür ist, kann ich nicht das Beispiel remeber aber es gab eine osteuropäische Sprache, deren Y sortiert werden nicht wie die Engländer Y. Dann gibt es die spanische ch die spanische Benutzer expet nach h sortiert werden. „

Ich bin ein Muttersprache Spanisch Lautsprecher und „ch“ ist kein Brief, sondern zwei „c“ und „h“ und das spanische Alphabet ist wie: abcdefghijklmn ñ opqrstuvwxyz Wir erwarten nicht, „ch“ nach „h“, sondern „i“ Das Alphabet ist die gleiche wie auf Englisch mit Ausnahme der ñ oder in HTML "& ntilde;"

Alex

TL; DR;
Unicode - (nchar, nvarchar und ntext)
Nicht-Unicode -. (Char, varchar und Text)

Von MSDN

Sortierungen in SQL Server-Regeln sorgen für Sortierung, Fall und Akzent Empfindlichkeitseigenschaften für Ihre Daten. Sortierungen, die mit verwendet werden, Zeichendatentypen wie char und varchar diktieren die Codepage und die entsprechenden Zeichen, die für diese Daten dargestellt werden können, Art.

Sie verwenden Standard-SQL-Sortierung SQL_Latin1_General_CP1_CI_AS Unter der Annahme, dann sollten folgende Skript drucken alle Symbole, die Sie in VARCHAR passen kann, da es ein Byte verwendet ein Zeichen (256 gesamt) zu speichern, wenn Sie auf der Liste sehen es nicht gedruckt - Sie brauchen NVARCHAR.

declare @i int = 0;
while (@i < 256)
begin
print cast(@i as varchar(3)) + '  '+  char(@i)  collate SQL_Latin1_General_CP1_CI_AS 
print cast(@i as varchar(3)) + '  '+ char(@i)  collate Japanese_90_CI_AS  
set @i = @i+1;
end

Wenn Sie Sortierungs ändern zu können sagen, japanisch Sie werden feststellen, dass alle die seltsamen europäischen Buchstaben in normalen gedreht und einige Symbole in ? Zeichen.

Unicode ist ein Standard für die Zuordnung von Codepunkte auf Zeichen. weil es ist so konzipiert, um alle Zeichen aller Sprachen der zur Deckung Welt gibt es keine Notwendigkeit für unterschiedlichen Codepages unterschiedlich zu behandeln Sätze von Zeichen. Wenn Sie Zeichendaten speichern, die reflektiert mehr Sprachen, immer Unicode-Datentypen (nchar, nvarchar und ntext) anstelle der Nicht-Unicode-Datentypen (char, varchar und Text).

Ansonsten Ihre Sortierung geht seltsam.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow