Warum gibt es noch einen varchar-Datentyp?

In vielen meiner Datenbanken sind Felder als varchars definiert. Dies war kein großes Problem, da ich in Amerika lebe und arbeite (wo die einzige Sprache, die existiert, "amerikanisch" ist. Ahem )

Nachdem ich ungefähr 5 Jahre mit Datenbanken gearbeitet habe, habe ich festgestellt, dass ich irgendwann Probleme mit der eingeschränkten Natur des varchar-Felds habe und meine Felder modifizieren muss, um Daten als nvarchars zu speichern. Nachdem ich eine Tabelle erneut aktualisieren musste, um ein varchar-Feld in ein nvarchar-Feld umzuwandeln, kam mir nur der Gedanke: Warum machen wir das immer noch so? Ich habe schon lange die mentale Entscheidung getroffen, alle neuen Textfelder in nvarchar zu definieren, anstatt in varchar. Das habe ich aus meinen Lehrbüchern gelernt, als ich vor 10 Jahren in der Schule war.

Es ist 2011 und es gab letztes Jahr eine neue Version von SQL Server. Warum unterstützen wir weiterhin einen varchar-Datentyp, wenn wir stattdessen nvarchar verwenden können / sollten?

Ich weiß, dass oft behauptet wird, dass nvarchars "doppelt so groß" wie varchars sind, so dass die Verwendung von Speicherplatz ein Argument für die Wartung von varcars sein könnte.

Benutzer von heute können jedoch ihre nvarchars so definieren, dass die Daten als UTF-8 statt als Standard-UTF-16 gespeichert werden, wenn sie Speicherplatz sparen möchten. Dies würde eine 8-Bit-Codierung ermöglichen, wenn dies in erster Linie wünschenswert ist, während sichergestellt wird, dass das seltene 2-8-Byte-Zeichen, das in die Datenbank eingefügt wird, nichts kaputt macht.

Vermisse ich etwas? Gibt es einen guten Grund, warum sich dies in den letzten 15-20 Jahren nicht geändert hat?

1. Die Arbeit mit varchar ist gut genug für viele westeuropäische Sprachen (Norwegisch, Dänisch, Deutsch, Französisch, Niederländisch usw.), die einigen Sortierungsproblemen unterliegen

2. Siehe dies auf SO varchar vs nvarchar Leistung nvarchar hat schwerwiegende Auswirkungen auf die Leistung

3. Dies ist im Vergleich zum Umgang mit Daten MDY vs DMY trivial

Neben den Antworten zu Standards und Kompatibilität sollte auch die Leistung berücksichtigt werden. Während Speicherplatz als billig akzeptiert wird, ignorieren DBAs / Entwickler häufig die Tatsache, dass die Abfrageleistung manchmal direkt mit der Zeilen- / Seitengröße einer Tabelle zusammenhängt. Wenn Sie NVARCHARanstatt VARCHAR(wenn nicht erforderlich) verwenden, wird die Zeilengröße für Ihre Zeichenfelder effektiv verdoppelt. Wenn Sie beispielsweise 5 oder 10 Felder mit einer Länge von 50 haben, möchten Sie möglicherweise weitere 500 Byte pro Zeile hinzufügen. Wenn Sie eine breite Tabelle haben, könnte dies jede Zeile auf mehrere Seiten verteilen und die Leistung beeinträchtigen.

In vielen Unternehmen ist immer noch eine große Anzahl von Anwendungen, Schnittstellen, Plattformen und Tools installiert, die Einzelbytezeichen annehmen. Datenbanken leben selten isoliert - sie sind Teil eines IT-Ökosystems. Wenn Sie Tausende von Komponenten und Millionen von Codezeilen haben, die von Einzelbytezeichen abhängen, brauchen Sie einen guten Grund, die Zeit und das Geld zu investieren, die für den Umstieg auf Unicode erforderlich sind. Änderungen in dieser Größenordnung können Jahre in Anspruch nehmen. In einigen Ländern ist Unicode noch relativ neu, selten oder wird nicht vollständig unterstützt.

VARCHAR und NVARCHAR sind beide Teil von ISO Standard SQL. Das Entfernen oder Ablehnen der VARCHAR-Unterstützung in SQL Server wäre ein Rückschritt in Bezug auf Kompatibilität und Portabilität.

Alternativ könnten Benutzer von heute ihre nvarchars definieren, um die Daten als UTF-8 anstelle des Standard-UTF-16 zu speichern, wenn sie Speicherplatz sparen möchten.

Genau damit arbeiten die meisten Open-Source-Datenbanken VARCHAR.

• MySQL bietet utf8und ucs2"Kollatierungen".
• In SQLite haben Sie die Wahl zwischen UTF-8 (Standardeinstellung) und UTF-16.
• PostgreSQL unterstützt UTF-8 (aber nicht UTF-16).

Es müssen keine zwei separaten Zeichenfolgentypen vorhanden sein.

Microsoft ist mit seiner Ansicht, dass 8-Bit-Zeichenfolgen für Legacy-Codierungen und Unicode = UTF-16 vorgesehen sind, die ungerade. Was wahrscheinlich mit der Windows-API selbst zusammenhängt charund wchar_tso behandelt.

Weil einige von uns leichtere, kleinere Anwendungen auf weniger als modernster Hardware bauen, für die keine Unicode-Funktionen erforderlich sind. Vielleicht müssen wir es später ändern, aber im Moment brauchen wir es einfach nicht. Ich mag es, wenn meine Strings die Hälfte des Platzes einnehmen, den sie sonst unter NVARCHAR hätten.