Schreibe Unterschiede zwischen varchar und nvarchar

Derzeit verwenden wir in unserer SQL Server 2012-Datenbank, varcharund das möchten wir ändern nvarchar. Ich habe dazu ein Skript generiert.

Meine Frage ist, gibt es irgendwelche Unterschiede in, wie SQL Server varcharSpalten gegen nvarcharSpalten schreibt ? Wir haben eine Reihe von Backend-Prozeduren, die mir Sorgen machen.

Bearbeiten:
Nicht sicher, ob dies hilft, aber die Spalten haben keine Indizes, f / k oder Einschränkungen.

Sie müssen sicherstellen, dass Sie Unicode-Zeichenfolgenliteralen ein N-Präfix voranstellen. Diese funktionieren beispielsweise anders, wenn der zugrunde liegende Datentyp ist NVARCHAR:

CREATE TABLE dbo.t(c NVARCHAR(32));

INSERT dbo.t(c) SELECT 'រៀន';
INSERT dbo.t(c) SELECT 'នរៀ';
INSERT dbo.t(c) SELECT N'រៀន';

SELECT c FROM dbo.t;

SELECT c FROM dbo.t WHERE c = 'រៀន';
SELECT c FROM dbo.t WHERE c = N'រៀន';

Ergebnisse:

c
----
??? -- not stored correctly
??? -- not stored correctly
រៀន -- stored correctly!

c
----
???
??? -- probably not expected, however all Unicode characters have been changed to ?

c
----
រៀន

Für Benutzer mobiler Geräte oder heruntergekommener Browser, die Box-Zeichen anstelle von tatsächlichen Unicode-Zeichen anzeigen, sieht dies folgendermaßen aus:

Die größte Sorge ist, dass nvarchar2 Bytes pro Zeichen verwendet werden, wohingegen 1 varcharverwendet wird. nvarchar(4000)Verwendet daher dieselbe Menge an Speicherplatz wie varchar(8000)*.

Zusätzlich zu all Ihren Charakterdaten, die doppelt so viel Speicherplatz benötigen, bedeutet dies auch:

• Möglicherweise müssen Sie kürzere nvarcharSpalten verwenden, um die Zeilen innerhalb des Spaltenlimits von 8060 Byte / 8000 Byte Zeichen zu halten.
• Wenn Sie nvarchar(max)Spalten verwenden, werden diese früher als üblich aus der Reihe verschoben varchar(max).
• Möglicherweise müssen Sie kürzere nvarcharSpalten verwenden, um die 900-Byte-Indexschlüsselbeschränkung einzuhalten (ich weiß nicht, warum Sie einen so großen Indexschlüssel verwenden möchten, aber Sie wissen es nie).

Abgesehen davon ist das Arbeiten mit nvarcharnicht viel anders, vorausgesetzt, Ihre Client-Software ist für Unicode ausgelegt. SQL Server konvertiert transparent ein nach varcharnach oben nvarchar, sodass Sie das N-Präfix für Zeichenfolgenliterale nur dann unbedingt benötigen, wenn Sie 2-Byte-Zeichen (dh Unicode) im Literal verwenden. Beachten Sie, dass das Casting nvarcharzu varbinaryanderen Ergebnissen führt als das Gleiche varchar. Der wichtige Punkt ist, dass Sie nicht jedes varchar-Literal sofort in ein nvarchar-Literal ändern müssen, um die Anwendung am Laufen zu halten, was den Prozess vereinfacht.

* Wenn Sie die Datenkomprimierung verwenden (die leichte Zeilenkomprimierung genug ist , erforderlich Enterprise Edition vor SQL Server 2016 SP1 ) werden Sie in der Regel finden ncharund nvarcharnicht mehr Platz eingenommen haben , als charund varcharaufgrund Unicode - Kompression (den SCSU - Algorithmus) .

Denken Sie, dass die folgenden Hauptunterschiede sind:

1. Nvarchar speichert UNICODE-Daten. Wenn Sie UNICODE- oder mehrsprachige Daten speichern möchten, ist nvarchar die richtige Wahl. Varchar speichert ASCII-Daten und sollte für den normalen Gebrauch der Datentyp Ihrer Wahl sein.
2. In Bezug auf die Speichernutzung verwendet nvarchar 2 Bytes pro Zeichen, während varchar 1 verwendet.
3. Der Beitritt eines VARCHAR zu NVARCHAR hat einen beachtlichen Leistungseinbruch zur Folge.
4. Möglicherweise wird ein N-Präfix benötigt, wenn Daten eingefügt werden: INSERT dbo.t (c) SELECT N'ʤ ʥ ʦ ʧ ʨ ';
5. Einige Experten empfehlen nvarchar immer, weil: Da alle modernen Betriebssysteme und Entwicklungsplattformen Unicode intern verwenden und nvarchar anstelle von varchar verwenden, werden Codierungskonvertierungen bei jedem Lesen oder Schreiben in die Datenbank vermieden

nvarchar war für die RDP-Merge-Replikation von einer mobilen Datenbank auf SQL Server 2005 erforderlich. Auch LTrim (), RTrim () und Trim () wurden häufig verwendet, da nvarchar Leerzeichen von der Dateneingabe nicht automatisch abschneidet (), während Varchar dies tat .

Mir ist nicht bekannt, ob sich dies in den letzten Jahren geändert hat oder nicht, aber nvarchar ist jetzt der Standard, der für Anmeldungen auf der .NET Simple Membership-Website für VS Pro 2017 in der generierten Datenbank verwendet wird.

Wenn Sie NVarchar über Varchar verwenden und MULTI-LINQUAL nicht unterstützen müssen, erhöhen Sie den Speicher für DB, Backups (lokal und extern). Moderne Datenbanken sollten beides unterstützen und alle Conversion-Treffer sollten im Design berücksichtigt werden.