Der wahre Grund, warum Sie NVARCHAR verwenden möchten, ist, wenn Sie anders haben Sprachen in derselben Spalte, Sie müssen die Spalten in T-SQL ohne Dekodierung ansprechen, Sie möchten die Daten "nativ" in SSMS sehen können oder Sie möchten auf Unicode standardisieren.
Wenn Sie die Datenbank als dummen Speicher behandeln, ist es durchaus möglich, breite Zeichenfolgen und unterschiedliche (sogar variable Längen) Codierungen in VARCHAR (z. B. UTF-8) zu speichern. Das Problem tritt auf, wenn Sie versuchen, zu codieren und zu decodieren, insbesondere wenn die Codepage für verschiedene Zeilen unterschiedlich ist. Es bedeutet auch, dass der SQL-Server nicht in der Lage sein wird, mit den Daten einfach umzugehen, um innerhalb von T-SQL nach (möglicherweise variabel) codierten Spalten abzufragen.
Die Verwendung von NVARCHAR vermeidet all dies.
Ich würde NVARCHAR für jede Spalte empfehlen, die vom Benutzer eingegebene Daten enthält, die relativ uneingeschränkt sind.
Ich würde VARCHAR für jede Spalte empfehlen, die ein natürlicher Schlüssel ist (wie ein Fahrzeugkennzeichen, SSN, Seriennummer, Service-Tag, Bestellnummer, Flughafenrufzeichen usw.), die normalerweise durch einen Standard oder eine Gesetzgebung oder Konvention definiert und eingeschränkt wird. Auch VARCHAR für vom Benutzer eingegeben und sehr eingeschränkt (wie eine Telefonnummer) oder ein Code (AKTIV/GESCHLOSSEN, J/N, M/F, M/S/T/W usw.). Es gibt absolut keinen Grund dafür NVARCHAR zu verwenden.
Also für eine einfache Regel:
VARCHAR, wenn garantiert, dass es eingeschränkt wirdNVARCHAR andernfalls
