Im Gegensatz zu einigen anderen RDBMS, die die Auswahl einer Kodierung zulassen, speichert SQL Server nur Unicode-Daten in UTF-16 (Little Endian) und Nicht-Unicode-Daten in einer 8-Bit-Codierung (Extended ASCII, DBCS oder EBCDIC) für jede Codepage, die durch die Sortierung des Felds impliziert wird.
Ihre Entscheidung, zu wählen UCS-2 ist sinnvoll genug, wenn man bedenkt, dass UTF-16 Mitte 1996 eingeführt und 2000 vollständig spezifiziert wurde. Viele andere Systeme verwenden (oder verwendeten) es ebenfalls (siehe:https://en.wikipedia.org/wiki/UTF-16#Usage ). Ihre Entscheidung, fortzufahren mit ihm könnte fragwürdiger sein, obwohl es wahrscheinlich daran liegt, dass Windows und .NET UTF-16 sind. Das physikalische Layout der Bytes ist zwischen UCS-2 und UTF-16 gleich, daher sollte ein Upgrade von Systemen von UCS-2 zur Unterstützung von UTF-16 rein funktional sein, ohne dass bestehende Daten geändert werden müssen.
Ähm, nein. Das Erstellen eines benutzerdefinierten benutzerdefinierten Typs über SQLCLR ist nicht , in irgendeiner Weise erhalten Sie einen Ersatz für jeden nativen Typ. Es ist sehr praktisch, etwas zu erstellen, um mit speziellen Daten umzugehen. Aber Zeichenfolgen, selbst mit einer anderen Codierung, sind alles andere als spezialisiert. Wenn Sie diesen Weg für Ihre Zeichenfolgendaten gehen, würde dies die Benutzerfreundlichkeit Ihres Systems zerstören, ganz zu schweigen von der Leistung, da Sie keine verwenden könnten eingebaute String-Funktionen. Wenn Sie etwas Speicherplatz sparen könnten, würden diese Gewinne durch das, was Sie an Gesamtleistung verlieren würden, zunichte gemacht. Das Speichern eines UDT erfolgt durch Serialisierung in ein VARBINARY . Also, um beliebige zu tun Zeichenfolgenvergleich ODER Sortierung, außerhalb eines "binären" / "ordinalen" Vergleichs, müssten Sie alle anderen Werte einzeln zurück in UTF-8 konvertieren, um dann den Zeichenfolgenvergleich durchzuführen, der sprachliche Unterschiede berücksichtigen kann.
Außerdem ist diese "Dokumentation" wirklich nur Beispielcode / Proof-of-Concept-Zeug. Der Code wurde 2003 geschrieben ( http://msftengprodsamples.codeplex.com/SourceControl/latest#Kilimanjaro_Trunk/Programmability/CLR/UTF8String/CS/UTF8String/Utf8String.cs ) für SQL Server 2005. Ich habe ein Skript zum Testen der Funktionalität gesehen, aber nichts, was die Leistung betrifft.
Ja, sehr sogar. Standardmäßig ist die Handhabung der eingebauten Funktionen nur für UCS-2. Aber ab SQL Server 2012 können Sie sie dazu bringen, den vollständigen UTF-16-Zeichensatz zu verarbeiten (ab Unicode Version 5 oder 6, abhängig von Ihrem Betriebssystem und der Version von .NET Framework), indem Sie eine der Sortierungen verwenden, die hat einen Namen, der auf _SC endet (d. h. ergänzende Zeichen).
Richtig. UTF-16 und UCS-2 verwenden beide 2-Byte-Codepunkte. Aber UTF-16 verwendet einige von ihnen paarweise (d. h. Surrogate Pairs), um zusätzliche Zeichen abzubilden. Die für diese Paare verwendeten Codepunkte sind in UCS-2 für diesen Zweck reserviert und werden daher nicht zur Zuordnung zu verwendbaren Symbolen verwendet. Aus diesem Grund können Sie jedes Unicode-Zeichen in SQL Server speichern und es wird korrekt gespeichert und abgerufen.
Richtig, wenn auch irreführend. Ja, UTF-8 hat eine variable Breite, aber UTF-16 ist auch geringfügig variabel, da alle ergänzenden Zeichen aus zwei Doppelbyte-Codepunkten bestehen. Daher verwendet UTF-16 entweder 2 oder 4 Bytes pro Symbol, obwohl UCS-2 immer 2 Bytes ist. Aber das ist nicht der irreführende Teil. Was irreführend ist, ist die Implikation, dass keine andere Unicode-Codierung alle anderen Codepunkte codieren kann. Während UCS-2 sie speichern, aber nicht interpretieren kann, können sowohl UTF-16 als auch UTF-32 alle Unicode-Codepunkte abbilden, genau wie UTF-8.
Das mag stimmen, ist aber aus betrieblicher Sicht völlig irrelevant.
Wieder richtig, aber völlig irrelevant, da UTF-16 und UTF-32 auch alle Unicode-Codepunkte abbilden.
Abhängig von den Umständen könnte dies sehr wohl wahr sein, und Sie sind zu Recht besorgt über eine solche verschwenderische Nutzung. Wie ich jedoch in der Frage erwähnt habe, die zu dieser geführt hat ( UTF-8-Unterstützung, SQL Server 2012 und UTF8String UDT
), haben Sie einige Optionen, um die Menge an verschwendetem Speicherplatz zu verringern, wenn die meisten Zeilen in VARCHAR passen einige müssen jedoch NVARCHAR sein . Die beste Option ist die Aktivierung von ROW COMPRESSION oder PAGE COMPRESSION (nur Enterprise Editon!). Ab SQL Server 2008 R2 lassen sie Nicht-MAX-NVARCHAR zu Felder, um das "Standard Compression Scheme for Unicode" zu verwenden, das mindestens so gut wie UTF-8 ist, und in einigen Fällen sogar besser als UTF-8. NVARCHAR(MAX) Felder können diese ausgefallene Komprimierung nicht verwenden , aber ihre IN ROW-Daten können von der regulären ROW- und/oder PAGE-Komprimierung profitieren. Nachfolgend finden Sie eine Beschreibung dieser Komprimierung und ein Diagramm zum Vergleich der Datengrößen für:unformatiertes UCS-2/UTF-16, UTF-8 und UCS-2/UTF-16 mit aktivierter Datenkomprimierung.
SQL Server 2008 R2 – UCS2-Komprimierung, was ist das – Auswirkung auf SAP-Systeme
Siehe auch die MSDN-Seite für Datenkomprimierung für weitere Details, da es einige Einschränkungen gibt (darüber hinaus ist es nur in der Enterprise Edition verfügbar -- ABER für alle verfügbar gemacht Editionen ab SQL Server 2016, SP1 !!) und einige Umstände, in denen die Komprimierung die Situation verschlimmern könnte.
Die Richtigkeit dieser Aussage hängt davon ab, wie man "Festplatte" definiert. Wenn Sie von handelsüblichen Teilen sprechen, die Sie in einem Geschäft für die Verwendung in Ihrem Desktop / Laptop ab Lager kaufen können, dann sicher. Wenn Sie jedoch von Speicher auf Unternehmensebene sprechen, der für Ihre Produktionssysteme verwendet wird, dann haben Sie Spaß daran, jedem, der das Budget kontrolliert, zu erklären, dass er das von Ihnen gewünschte Millionen-Dollar-SAN nicht ablehnen sollte, weil es „billig“ ist ";-).
Keine, die ich mir vorstellen kann. Nun, solange Sie keinem schrecklichen Rat folgen, um so etwas wie das Implementieren dieses UDT oder das Konvertieren aller Zeichenfolgen in VARBINARY zu tun , oder mit NVARCHAR(MAX) für alle Stringfelder;-). Aber von all den Dingen, über die Sie sich Sorgen machen könnten, sollte SQL Server mit UCS-2 / UTF-16 keines davon sein.
Aber wenn aus irgendeinem Grund dieses Problem der fehlenden nativen Unterstützung für UTF-8 sehr wichtig ist, müssen Sie möglicherweise ein anderes RDBMS finden, das UTF-8 unterstützt.
UPDATE 02.10.2018
Obwohl dies noch keine praktikable Option ist, führt SQL Server 2019 die native Unterstützung für UTF-8 in VARCHAR ein / CHAR Datentypen. Derzeit gibt es zu viele Fehler, als dass es verwendet werden könnte, aber wenn sie behoben sind, dann ist dies eine Option für einige Szenarien. Bitte lesen Sie meinen Beitrag „Native UTF-8-Unterstützung in SQL Server 2019:Retter oder falscher Prophet?
", für eine detaillierte Analyse dieser neuen Funktion.
