it-swarm.com.de

Was ist der Unterschied zwischen varchar und nvarchar?

Ist es nur so, dass nvarchar Multibyte-Zeichen unterstützt? Wenn dies der Fall ist, gibt es wirklich einen anderen Grund als Speicherprobleme, varchars zu verwenden?

1283
stimms

In einer nvarchar -Spalte können beliebige Unicode-Daten gespeichert werden. Eine varchar -Spalte ist auf eine 8-Bit-Codepage beschränkt. Einige Leute denken, dass varchar verwendet werden sollte, weil es weniger Platz beansprucht. Ich glaube das ist nicht die richtige Antwort. Codepage-Inkompatibilitäten sind ein Schmerz und Unicode ist die Lösung für Codepage-Probleme. Heutzutage gibt es mit billiger Festplatte und billigem Speicher keinen Grund mehr, Zeit mit Codepages zu verschwenden.

Alle modernen Betriebssysteme und Entwicklungsplattformen verwenden Unicode intern. Durch die Verwendung von nvarchar anstelle von varchar können Sie vermeiden, dass jedes Mal, wenn Sie aus der Datenbank lesen oder in die Datenbank schreiben, Codierungskonvertierungen durchgeführt werden. Konvertierungen brauchen Zeit und sind fehleranfällig. Die Behebung von Konvertierungsfehlern ist ein nicht triviales Problem.

Wenn Sie mit einer Anwendung arbeiten, die nur ASCII verwendet, würde ich weiterhin die Verwendung von Unicode in der Datenbank empfehlen. Die Betriebssystem- und Datenbank-Kollatierungsalgorithmen funktionieren mit Unicode besser. Unicode vermeidet Konvertierungsprobleme bei der Anbindung an andere Systeme. Und Sie bereiten sich auf die Zukunft vor. Sie können jederzeit überprüfen, ob Ihre Daten auf 7-Bit ASCII beschränkt sind, unabhängig davon, welches Legacy-System Sie warten müssen, und gleichzeitig einige der Vorteile des vollständigen Unicode-Speichers nutzen.

1561

varchar : Nicht-Unicode-Zeichendaten mit variabler Länge. Die Datenbanksortierung bestimmt, mit welcher Codepage die Daten gespeichert werden.

nvarchar : Unicode-Zeichendaten variabler Länge. Abhängig von der Datenbanksortierung für Vergleiche.

Verwenden Sie mit diesem Wissen dasjenige, das Ihren Eingabedaten entspricht (ASCII v. Unicode).

240
user7116

Ich benutze immer nvarchar, da alles, was ich baue, so gut wie allen Daten standhält, die ich darauf wirfe. Mein CMS-System kann aus Versehen Chinesisch, weil ich nvarchar verwendet habe. Heutzutage sollten sich neue Anwendungen nicht mehr wirklich mit dem erforderlichen Speicherplatz befassen.

64
tags2k

Dies hängt davon ab, wie Oracle installiert wurde. Während des Installationsvorgangs wird die Option NLS_CHARACTERSET festgelegt. Möglicherweise können Sie es mit der Abfrage SELECT value$ FROM sys.props$ WHERE name = 'NLS_CHARACTERSET' finden.

Wenn Ihr NLS_CHARACTERSET eine Unicode-Codierung wie UTF8 ist, ist das großartig. Die Verwendung von VARCHAR und NVARCHAR ist nahezu identisch. Hör jetzt auf zu lesen, mach einfach. Andernfalls oder wenn Sie keine Kontrolle über den Oracle-Zeichensatz haben, lesen Sie weiter.

VARCHAR - Daten werden in der Codierung NLS_CHARACTERSET gespeichert. Wenn sich andere Datenbankinstanzen auf demselben Server befinden, werden Sie möglicherweise von diesen eingeschränkt. und umgekehrt, da du die einstellung teilen musst. In einem solchen Feld können alle Daten gespeichert werden, die mit diesem Zeichensatz codiert werden können, und sonst nichts. Wenn der Zeichensatz beispielsweise MS-1252 ist, können Sie nur Zeichen wie englische Buchstaben, eine Handvoll Buchstaben mit Akzenten und einige andere (wie € und -) speichern. Ihre Anwendung ist nur für einige wenige Gebietsschemas nützlich, die nicht in der Lage sind, irgendwo anders auf der Welt zu arbeiten. Aus diesem Grund wird es als eine schlechte Idee angesehen.

NVARCHAR - Daten werden in einer Unicode-Codierung gespeichert. Jede Sprache wird unterstützt. Eine gute Idee.

Was ist mit Speicherplatz? VARCHAR ist im Allgemeinen effizient, da der Zeichensatz/die Codierung für ein bestimmtes Gebietsschema angepasst wurde. NVARCHAR-Felder werden entweder in UTF-8- oder UTF-16-Codierung gespeichert, wobei ironischerweise die NLS-Einstellung zugrunde gelegt wird. UTF-8 ist sehr effizient für "westliche" Sprachen, unterstützt jedoch weiterhin asiatische Sprachen. UTF-16 ist für asiatische Sprachen sehr effizient, unterstützt jedoch weiterhin "westliche" Sprachen. Wenn Sie sich Gedanken über den Speicherplatz machen, wählen Sie eine NLS-Einstellung, damit Oracle UTF-8 oder UTF-16 verwendet.

Was ist mit der Verarbeitungsgeschwindigkeit? Die meisten neuen Codierungsplattformen verwenden Unicode nativ (Java, .NET, sogar C++ std :: wstring von vor Jahren!). Wenn das Datenbankfeld also VARCHAR ist, wird Oracle gezwungen, bei jedem Lesen oder Schreiben zwischen Zeichensätzen zu konvertieren, was nicht so gut ist. Die Verwendung von NVARCHAR vermeidet die Konvertierung.

Fazit: Verwenden Sie NVARCHAR! Es vermeidet Einschränkungen und Abhängigkeiten, ist ausreichend für den Speicherplatz und in der Regel auch für die Leistung.

28
Jeremy Frank

nvarchar speichert Daten als Unicode. Wenn Sie also mehrsprachige Daten (mehr als eine Sprache) in einer Datenspalte speichern möchten, benötigen Sie die N-Variante.

17
albertein

Meine zwei Cent

  1. Indizes können fehlschlagen, wenn nicht die richtigen Datentypen verwendet werden:
    In SQL Server: Wenn Sie über einen Index für eine VARCHAR-Spalte verfügen und diesen als Unicode-Zeichenfolge anzeigen, verwendet SQL Server den Index nicht. Dasselbe passiert, wenn Sie einer indizierten Spalte, die SmallInt enthält, ein BigInt präsentieren. Selbst wenn das BigInt klein genug ist, um ein SmallInt zu sein, kann SQL Server den Index nicht verwenden. Umgekehrt besteht dieses Problem nicht (wenn Sie SmallInt- oder Ansi-Code für eine indizierte BigInt- oder NVARCHAR-Spalte bereitstellen).

  2. Datentypen können zwischen verschiedenen DBMS (DataBase Management System) variieren:
    Wissen Sie, dass jede Datenbank leicht unterschiedliche Datentypen hat und VARCHAR nicht überall dasselbe bedeutet. Während SQL Server VARCHAR und NVARCHAR hat, hat eine Apache/Derby-Datenbank nur VARCHAR und dort ist VARCHAR in Unicode.

14
incomudro

Hauptsächlich nvarchar speichert Unicode-Zeichen und varchar speichert Nicht-Unicode-Zeichen.

"Unicodes" bedeutet ein 16-Bit-Zeichencodierungsschema, mit dem Zeichen aus vielen anderen Sprachen wie Arabisch, Hebräisch, Chinesisch und Japanisch in einem einzigen Zeichensatz codiert werden können.

Das bedeutet, dass Unicodes 2 Bytes pro Zeichen zum Speichern verwendet und Nonunicodes nur ein Byte pro Zeichen zum Speichern verwendet. Das bedeutet, dass Unicodes im Vergleich zu Nicht-Unicodes eine doppelte Speicherkapazität benötigen.

12
ranjit pawar

Ich würde sagen, es kommt darauf an.

Wenn Sie eine Desktop-Anwendung entwickeln, bei der das Betriebssystem in Unicode (wie alle aktuellen Windows-Systeme) und die Sprache nativ Unicode unterstützen (Standardzeichenfolgen sind Unicode, wie in Java oder C #), gehen Sie zu nvarchar.

Wenn Sie eine Webanwendung entwickeln, bei der Zeichenfolgen als UTF-8 eingegeben werden und die Sprache PHP ist, das Unicode (in Version 5.x) immer noch nicht unterstützt, ist varchar wahrscheinlich die bessere Wahl.

9
sleepy012

Du hast recht. nvarchar speichert Unicode-Daten, während varchar Einzelbyte-Zeichendaten speichert. Abgesehen von den Speicherdifferenzen (nvarchar erfordert doppelt so viel Speicherplatz wie varchar), die Sie bereits erwähnt haben, wäre der Hauptgrund für den Vorzug von nvarchar gegenüber varchar die Internationalisierung (dh Speicherung) Saiten in anderen Sprachen).

9
Mike Spross

Obwohl NVARCHAR Unicode speichert, sollten Sie mithilfe der Sortierung berücksichtigen, dass Sie VARCHAR auch verwenden und Ihre Daten in Ihrer Landessprache speichern können.

Stellen Sie sich das folgende Szenario vor.

Die Kollatierung Ihrer DB ist persisch und Sie speichern einen Wert wie 'علی' (persisches Schreiben von ALi) im Datentyp VARCHAR(10). Es gibt kein Problem und das DBMS verwendet nur drei Bytes, um es zu speichern.

Wenn Sie jedoch Ihre Daten in eine andere Datenbank übertragen möchten und das richtige Ergebnis sehen möchten, muss Ihre Zieldatenbank dieselbe Sortierung haben wie das Ziel, das in diesem Beispiel persisch ist.

Wenn sich Ihre Zielsortierung unterscheidet, werden in der Zieldatenbank Fragezeichen (?) Angezeigt.

Denken Sie schließlich daran, wenn Sie eine große Datenbank verwenden, die für die Verwendung Ihrer Landessprache vorgesehen ist, würde ich empfehlen, den Speicherort zu verwenden, anstatt zu viele Leerzeichen zu verwenden.

Ich glaube, das Design kann anders sein. Das hängt von der Umgebung ab, in der Sie arbeiten.

6
Ali Elmi

Wenn ein einzelnes Byte zum Speichern eines Zeichens verwendet wird, gibt es 256 mögliche Kombinationen, und Sie können dadurch 256 verschiedene Zeichen speichern. Kollatierung ist das Muster, das die Zeichen und die Regeln definiert, nach denen sie verglichen und sortiert werden.

1252, das Latin1 (ANSI), ist am häufigsten. Einzelbyte-Zeichensätze reichen auch nicht aus, um alle von vielen Sprachen verwendeten Zeichen zu speichern. Beispielsweise haben einige asiatische Sprachen Tausende von Zeichen, sodass sie zwei Bytes pro Zeichen verwenden müssen.

Unicode-Standard

Wenn Systeme, die mehrere Codepages verwenden, in einem Netzwerk verwendet werden, wird es schwierig, die Kommunikation zu verwalten. Um die Dinge zu standardisieren, führte das ISO- und Unicode-Konsortium nicode ein. Unicode verwendet zwei Bytes, um jedes Zeichen zu speichern. Das heißt, 65.536 verschiedene Zeichen können definiert werden, sodass fast alle Zeichen mit Unicode abgedeckt werden können. Wenn zwei Computer Unicode verwenden, wird jedes Symbol auf dieselbe Weise dargestellt, und es ist keine Konvertierung erforderlich - das ist die Idee hinter Unicode.

SQL Server verfügt über zwei Kategorien von Zeichendatentypen:

  • nicht-Unicode (char, varchar und text)
  • Unicode (nchar, nvarchar und ntext)

Wenn wir Zeichendaten aus mehreren Ländern speichern müssen, verwenden Sie immer Unicode.

6
Jithin Shaji

mit nVarchar können Sie Unicode-Zeichen speichern. Dies ist der richtige Weg, um lokalisierte Daten zu speichern.

6
Vijesh VP

Ich muss hier sagen (mir ist klar, dass ich mich wahrscheinlich für einen Slating öffnen werde!), Aber sicherlich das einzige Mal, wenn NVARCHAR tatsächlich mehr ist nützlich (beachte das mehr da!) als VARCHAR ist, wenn alle Kollatierungen auf allen abhängigen Systemen vorhanden sind und innerhalb der Datenbank selbst sind die gleichen ...? Wenn nicht, muss die Sortierumwandlung trotzdem stattfinden und macht VARCHAR genauso rentabel wie NVARCHAR.

Dazu haben einige Datenbanksysteme wie SQL Server (vor 2012) eine Seitengröße von ca. 8 TAUSEND. Wenn Sie also durchsuchbare Daten speichern möchten, die nicht in so etwas wie TEXT oder NTEXT enthalten sind, bietet VARCHAR den vollen Speicherplatz von 8 KB, während NVARCHAR nur Platz bietet 4k (verdoppeln Sie die Bytes, verdoppeln Sie den Raum).

Ich nehme an, um zusammenzufassen, die Verwendung von entweder ist abhängig von:

  • Projekt oder Kontext
  • Infrastruktur
  • Datenbanksystem
5
Paul

Der Hauptunterschied zwischen Varchar(n) und nvarchar(n) ist: enter image description here

Die Größe von Varchar (Nicht-Unicode-Zeichendaten mit variabler Länge) beträgt bis zu 8000. 1. Es handelt sich um einen Datentyp mit variabler Länge

  1. Dient zum Speichern von Nicht-Unicode-Zeichen

  2. Belegt 1 Byte Platz für jedes Zeichen

enter image description here

Nvarchar: Unicode-Zeichendaten variabler Länge.

1. Es ist ein Datentyp mit variabler Länge

2. Zum Speichern von Unicode-Zeichen.

  1. Daten werden in einer Unicode-Codierung gespeichert. Jede Sprache wird unterstützt. (zum Beispiel die Sprachen Arabisch, Deutsch, Hindi usw. usw.)
5
Debendra Dash

Ich habe mir die Antworten angeschaut und viele scheinen zu empfehlen, nvarchar anstelle von varchar zu verwenden, da der Speicherplatz kein Problem mehr darstellt und es daher keinen Nachteil darstellt, Unicode für wenig zusätzlichen Speicherplatz zu aktivieren. Dies ist nicht immer der Fall, wenn Sie einen Index auf Ihre Spalte anwenden möchten. SQL Server hat ein Limit von 900 Byte für die Größe des Felds, das Sie indizieren können. Wenn Sie also eine varchar(900) haben, können Sie diese trotzdem indizieren, aber nicht varchar(901). Mit nvarchar wird die Anzahl der Zeichen halbiert, sodass Sie bis zu nvarchar(450) indizieren können. Wenn Sie also sicher sind, dass Sie nvarchar nicht benötigen, empfehle ich, es nicht zu verwenden.

Im Allgemeinen empfehle ich in Datenbanken, die von Ihnen benötigte Größe beizubehalten, da Sie diese jederzeit erweitern können. Zum Beispiel hat ein Kollege bei der Arbeit einmal gedacht, dass die Verwendung von nvarchar(max) für eine Spalte keinen Schaden anrichtet, da wir überhaupt kein Problem mit der Speicherung haben. Als wir später versuchten, einen Index auf diese Spalte anzuwenden, lehnte SQL Server dies ab. Wenn er jedoch mit sogar varchar(5) begonnen hätte, hätten wir es später einfach auf das erweitern können, was wir benötigen, ohne dass wir einen Feldmigrationsplan erstellen müssten, um dieses Problem zu beheben.

5
Rafid

Folgen Sie nterschied zwischen SQL Server VARCHAR und NVARCHAR-Datentyp. Hier konnte man sehr anschaulich sehen.

Im Allgemeinen speichert nvarchar Daten als Unicode. Wenn Sie also mehrsprachige Daten (mehr als eine Sprache) in einer Datenspalte speichern möchten, benötigen Sie die N-Variante.

5

Jeffrey L Whitledge mit ~ 47000 Reputationspunkten empfiehlt die Verwendung von nvarchar

Solomon Rutzky mit einem Reputationswert von ~ 33200 empfiehlt: Verwenden Sie NICHT immer NVARCHAR. Das ist eine sehr gefährliche und oft kostspielige Haltung.

Was sind die wichtigsten Leistungsunterschiede zwischen den SQL Server-Datentypen varchar und nvarchar?

https://www.sqlservercentral.com/articles/disk-is-cheap-orly-4

Was wählt ein lernender SQL Server-Datenbankentwickler aus, der beide ein so hohes Ansehen besitzt?

Es gibt viele Warnungen in Antworten und Kommentaren zu Leistungsproblemen, wenn Sie bei der Auswahl nicht konsistent sind.

Es gibt Kommentare pro/con nvarchar für die Leistung.

Es gibt Kommentare pro/con varchar für die Leistung.

Ich habe eine besondere Anforderung an eine Tabelle mit vielen hundert Spalten, was an sich wahrscheinlich ungewöhnlich ist?

Ich entscheide mich für varchar, um die Beschränkung der Datensatzgröße für 8060-Byte-Tabellen von SQL * Server 2012 nicht zu überschreiten.

Die Verwendung von nvarchar überschreitet für mich diese 8060-Byte-Grenze.

Ich denke auch, dass ich die Datentypen der zugehörigen Codetabellen mit den Datentypen der primären zentralen Tabelle abgleichen sollte.

Ich habe bei früheren erfahrenen Datenbankentwicklern an diesem Arbeitsplatz, der südaustralischen Regierung, die Verwendung von varchar-Spalten gesehen, bei denen die Anzahl der Tabellenzeilen mehrere Millionen oder mehr betragen wird (und bei diesen sehr großen Spalten nur sehr wenige nvarchar-Spalten, falls vorhanden) Tabellen), so wird möglicherweise das erwartete Datenzeilenvolumen Teil dieser Entscheidung.

1
Allan F

nvarchar ist im Vergleich zu varchar sicher, um unseren Code fehlerfrei zu machen (Typinkongruenz), da nvarchar auch Unicode-Zeichen zulässt. Wenn wir die Bedingung where in der SQL Server-Abfrage verwenden und den Operator = verwenden, wird der Fehler einige Male ausgelöst. Wahrscheinlicher Grund dafür ist, dass unsere Mapping-Spalte in varchar abweicht. Wenn wir es in nvarchar definiert haben, ist dieses Problem nicht aufgetreten. Trotzdem bleiben wir bei varchar und vermeiden dieses Problem, indem wir besser LIKE als = verwenden.

0
Rinoy Ashokan