NVarchar vs Varchar

Jeder Entwickler, der eine neue String-Spalte definiert, entscheidet: Verwende ich nvarchar oder verwende ich varchar?

Seit ich nvarchar entdeckt habe, verwende ich immer nvarchar. Mein Gedanke ist: Warum einen Datentyp verwenden, der möglicherweise einen Textwert nicht unterstützt, und du wirst wahrscheinlich erst einen Inkompatibilitätswert entdecken, wenn er in der Produktion ist.

Ich höre das Argument über den Speicherplatz, aber Speicherplatz ist billig und nicht der Sorge wert. Ich weiß, was du denkst: Die Kosten spielen keine Rolle, wenn die Festplatte voll ist, und da stimme ich zu.

Ab SQL Server 2008 R2 wird Datenkomprimierung auf nchar- und nvarchar-Felder angewendet (nvarchar(max) ist ausgeschlossen). Je nach Daten variiert die Effektivität der Komprimierung, aber bei Englisch gibt es eine 50%ige Komprimierung, was es mit dem Speicherbedarf von varchar gleichstellt (1).

Etwas anderes zu bedenken ist, dass die meisten Programmiersprachen UTF-16 als String-Typ unterstützen. Jedes Mal, wenn ein varchar aus der Datenbank geladen wird, wird es zu UTF-16 (nvarchar-ähnlich) konvertiert.

Diese StackOverflow-Antwort fasst nvarchar vs. varchar zusammen:

Eine nvarchar-Spalte kann beliebige Unicode-Daten speichern. Eine varchar-Spalte ist auf eine 8-Bit-Codepage beschränkt. Manche Leute denken, dass varchar verwendet werden sollte, weil es weniger Platz benötigt. Ich glaube, das ist nicht die richtige Antwort. Codepage-Inkompatibilitäten sind ein Problem, und Unicode ist die Lösung für Codepage-Probleme. Mit billigen Festplatten und Speicher heutzutage gibt es wirklich keinen Grund, Zeit mit dem Herumhantieren an Codepages zu verschwenden.

Alle modernen Betriebssysteme und Entwicklungsplattformen verwenden intern Unicode. Durch die Verwendung von nvarchar anstatt varchar kannst du vermeiden, Kodierungskonvertierungen jedes Mal durchzuführen, wenn du aus der Datenbank liest oder in sie schreibst. Konvertierungen brauchen Zeit und sind fehleranfällig. Und die Wiederherstellung von Konvertierungsfehlern ist ein nicht-triviales Problem.

Wenn du mit einer Anwendung arbeitest, die nur ASCII verwendet, würde ich trotzdem empfehlen, Unicode in der Datenbank zu verwenden. Die Betriebssystem- und Datenbank-Sortieralgorithmen funktionieren besser mit Unicode. Unicode vermeidet Konvertierungsprobleme bei der Schnittstelle mit anderen Systemen. Und du bereitest dich auf die Zukunft vor. Und du kannst immer validieren, dass deine Daten auf 7-Bit-ASCII für welches Legacy-System auch immer du warten musst beschränkt sind, während du einige der Vorteile der vollständigen Unicode-Speicherung genießt. (2)

Mein Fazit ist, dass die Daten nur dann varchar sind, wenn sie ruhen.

Referenzen:

1. Unicode Compression implementation
2. What is the difference between varchar and nvarchar?