Na rozdíl od některých jiných RDBMS, které umožňují výběr kódování, SQL Server ukládá data Unicode pouze v UTF-16 (Little Endian) a data nekódovaná Unicode v 8bitovém kódování (Extended ASCII, DBCS nebo EBCDIC) pro jakoukoli kódovou stránku, která je implikována porovnáváním pole.
Jejich rozhodnutí vybrat UCS-2 dává smysl vzhledem k tomu, že UTF-16 bylo představeno v polovině roku 1996 a plně specifikováno v roce 2000. Mnoho dalších systémů jej také používá (nebo používá) (viz:https://en.wikipedia.org/wiki/UTF-16#Usage ). Jejich rozhodnutí pokračovat s tím by to mohlo být spornější, i když je to pravděpodobně způsobeno tím, že Windows a .NET jsou UTF-16. Fyzické rozložení bajtů je mezi UCS-2 a UTF-16 stejné, takže upgrade systémů z UCS-2 na podporu UTF-16 by měl být čistě funkční bez nutnosti měnit jakákoli existující data.
Um, ne. Vytvoření vlastního uživatelem definovaného typu pomocí SQLCLR není , jakýmkoliv způsobem vám zajistí náhradu jakéhokoli nativního typu. Je to velmi užitečné pro vytvoření něčeho, co zpracovává specializovaná data. Ale řetězce, byť s jiným kódováním, nejsou ani zdaleka specializované. Jít touto cestou pro data řetězců by zničilo jakékoli množství použitelnosti vašeho systému, nemluvě o výkonu, protože byste nemohli použít žádné vestavěné funkce řetězce. Pokud byste byli schopni ušetřit cokoli na disku, tyto zisky by byly vymazány tím, co byste ztratili na celkovém výkonu. Uložení UDT se provádí jeho serializací do VARBINARY . Chcete-li tedy provést jakékoli porovnávání řetězců NEBO třídění, mimo "binární" / "ordinální" srovnání byste museli převést všechny ostatní hodnoty, jednu po druhé, zpět do UTF-8, abyste pak provedli porovnání řetězců, které může zohlednit lingvistické rozdíly.
Také tato "dokumentace" je ve skutečnosti jen ukázkový kód / důkaz koncepčních věcí. Kód byl napsán v roce 2003 ( http://msftengprodsamples.codeplex.com/SourceControl/latest#Kilimanjaro_Trunk/Programmability/CLR/UTF8String/CS/UTF8String/Utf8String.cs ) pro SQL Server 2005. Viděl jsem skript k testování funkčnosti, ale nic nezahrnovalo výkon.
Ano, velmi. Ve výchozím nastavení je obsluha vestavěných funkcí pouze pro UCS-2. Ale počínaje SQL Server 2012 je můžete přimět, aby zpracovávaly celou znakovou sadu UTF-16 (také od verze Unicode 5 nebo 6, v závislosti na vašem operačním systému a verzi rozhraní .NET Framework) pomocí jednoho z porovnávání, které má název končící na _SC (tj. doplňkové znaky).
Opravit. UTF-16 a UCS-2 používají 2bajtové kódové body. Ale UTF-16 používá některé z nich v párech (tj. náhradní páry) k mapování dalších znaků. Kódové body použité pro tyto páry jsou vyhrazeny pro tento účel v UCS-2, a proto se nepoužívají k mapování na žádné použitelné symboly. To je důvod, proč můžete uložit jakýkoli znak Unicode na SQL Server a bude uložen a načten správně.
Správné, i když zavádějící. Ano, UTF-8 má proměnnou šířku, ale UTF-16 je také mírně proměnlivé, protože všechny doplňkové znaky se skládají ze dvou dvoubajtových kódových bodů. Proto UTF-16 používá buď 2 nebo 4 bajty na symbol, ačkoli UCS-2 je vždy 2 bajty. Ale to není ta zavádějící část. Co je zavádějící, je důsledek, že jakékoli jiné kódování Unicode není schopné zakódovat všechny ostatní body kódu. Zatímco UCS-2 je může pojmout, ale neinterpretovat, UTF-16 i UTF-32 mohou mapovat všechny body kódu Unicode, stejně jako UTF-8.
To může být pravda, ale z provozního hlediska je to zcela irelevantní.
Znovu, pravda, ale zcela irelevantní, protože UTF-16 a UTF-32 také mapují všechny body kódu Unicode.
V závislosti na okolnostech to může být velmi dobře pravda a máte pravdu, že se obáváte o takové plýtvání. Jak jsem však zmínil v otázce, která k tomu vede ( Podpora UTF-8, SQL Server 2012 a UTF8String UDT
), máte několik možností, jak zmírnit množství plýtvaného místa, pokud se většina řádků vejde do VARCHAR přesto některé musí být NVARCHAR . Nejlepší možností je povolit KOMPRESI ŘÁDKŮ nebo KOMPRESE STRÁNEK (pouze Enterprise Editon!). Počínaje SQL Server 2008 R2 umožňují neMAX NVARCHAR pole použít "Standard Compression Scheme for Unicode", které je přinejmenším stejně dobré jako UTF-8 a v některých případech je dokonce lepší než UTF-8. NVARCHAR(MAX) pole nemohou tuto efektní kompresi používat , ale jejich data IN ROW mohou těžit z běžné komprese ROW a/nebo PAGE. Níže naleznete popis této komprese a graf srovnávající velikosti dat pro:nezpracované UCS-2 / UTF-16, UTF-8 a UCS-2 / UTF-16 s povolenou kompresí dat.
SQL Server 2008 R2 – komprese UCS2, co to je – Dopad na systémy SAP
Podívejte se také na stránku MSDN pro komprese dat pro více podrobností, protože existují určitá omezení (kromě toho, že je k dispozici pouze v Enterprise Edition – ALE zpřístupněno všem edice počínaje SQL Server 2016, SP1!!) a za určitých okolností, kdy komprese může situaci zhoršit.
Pravdivost tohoto tvrzení závisí na tom, jak člověk definuje „disk“. Pokud mluvíte z hlediska komoditních dílů, které si můžete koupit z regálu v obchodě pro použití ve vašem stolním počítači / notebooku, pak jistě. Ale pokud mluvíme o úložišti na podnikové úrovni, které bude použito pro vaše produkční systémy, pak se bavte vysvětlováním komukoli, kdo kontroluje rozpočet, že by neměli odmítat SAN za milion dolarů, které chcete, protože je „levný“. ";-).
Žádný, co by mě napadlo. No, pokud se nebudete řídit nějakou příšernou radou, abyste udělali něco, jako je implementace tohoto UDT nebo převod všech řetězců na VARBINARY nebo pomocí NVARCHAR(MAX) pro všechna pole řetězců;-). Ale ze všech věcí, kterých byste se mohli obávat, by SQL Server používající UCS-2 / UTF-16 neměl být jednou z nich.
Pokud je však z nějakého důvodu tento problém s nativní podporou UTF-8 velmi důležitý, možná budete muset najít jiný RDBMS, který by umožňoval UTF-8.
AKTUALIZACE 2018-10-02
I když to zatím není schůdná možnost, SQL Server 2019 zavádí nativní podporu pro UTF-8 v VARCHAR / CHAR typy dat. V současné době je v něm příliš mnoho chyb na to, aby se dal použít, ale pokud jsou opraveny, pak je to pro některé možnost scénáře. Podívejte se prosím na můj příspěvek, "Nativní podpora UTF-8 v SQL Server 2019:Spasitel nebo Falešný prorok?
“, pro podrobnou analýzu této nové funkce.