UCS-2 и SQL Server

За разлика от някои други RDBMS, които позволяват избор на кодиране, SQL Server съхранява Unicode данни само в UTF-16 (Little Endian) и не-Unicode данни в 8-битово кодиране (Extended ASCII, DBCS или EBCDIC) за всяка кодова страница, която се подразбира от съпоставянето на полето.

Тяхното решение за избор UCS-2 има достатъчно смисъл, като се има предвид, че UTF-16 беше въведен в средата на 1996 г. и напълно специфициран през 2000 г. Много други системи също го използват (или са го използвали) (моля, вижте:https://en.wikipedia.org/wiki/UTF-16#Usage ). Решението им да продължат с това може да е по-съмнително, въпреки че вероятно се дължи на това, че Windows и .NET са UTF-16. Физическото оформление на байтовете е едно и също между UCS-2 и UTF-16, така че надграждането на системи от UCS-2 за поддръжка на UTF-16 трябва да бъде чисто функционално, без да е необходимо да се променят съществуващи данни.

Хм, не. Създаването на потребителски дефиниран от потребителя тип чрез SQLCLR не е , по какъвто и да е начин, ще ви осигури заместител на произволен роден тип. Много е удобно за създаване на нещо, което да обработва специализирани данни. Но низовете, дори с различно кодиране, далеч не са специализирани. Тръгването по този път за вашите низови данни би унищожило каквато и да е използваемост на вашата система, да не говорим за производителността, тъй като не бихте могли да използвате никое вградени низови функции. Ако успеете да спестите нещо от дисковото пространство, тези печалби ще бъдат изтрити от това, което ще загубите в цялостната производителност. Съхраняването на UDT се извършва чрез сериализирането му в VARBINARY . Така че, за да направите всяко сравнение на низове ИЛИ сортиране, извън "двоично" / "редно" сравнение, ще трябва да конвертирате всички други стойности, една по една, обратно в UTF-8, за да направите след това сравнение на низове, което може да отчете езиковите разлики.

Освен това тази „документация“ всъщност е просто примерен код/доказателство за концептуални неща. Кодът е написан през 2003 г. ( http://msftengprodsamples.codeplex.com/SourceControl/latest#Kilimanjaro_Trunk/Programmability/CLR/UTF8String/CS/UTF8String/Utf8String.cs ) за SQL Server 2005. Видях скрипт за тестване на функционалност, но нищо, включващо производителност.

Да, много така. По подразбиране обработката на вградените функции е само за UCS-2. Но започвайки от SQL Server 2012, можете да ги накарате да обработват пълния набор от знаци UTF-16 (е, от Unicode версия 5 или 6, в зависимост от вашата операционна система и версия на .NET Framework), като използвате едно от съпоставянията, които има име, завършващо на _SC (т.е. допълнителни знаци).

Правилно. UTF-16 и UCS-2 използват 2-байтови кодови точки. Но UTF-16 използва някои от тях по двойки (т.е. сурогатни двойки), за да картографира допълнителни знаци. Кодовите точки, използвани за тези двойки, са запазени за тази цел в UCS-2 и следователно не се използват за картографиране към използваеми символи. Ето защо можете да съхранявате всеки Unicode знак в SQL Server и той ще бъде съхранен и извлечен правилно.

Правилно, макар и подвеждащо. Да, UTF-8 е с променлива ширина, но UTF-16 също е незначително променлив, тъй като всички допълнителни знаци са съставени от две двубайтови кодови точки. Следователно UTF-16 използва 2 или 4 байта на символ, въпреки че UCS-2 винаги е 2 байта. Но това не е подвеждащата част. Това, което е подвеждащо, е внушението, че всяко друго Unicode кодиране не е в състояние да кодира всички други кодови точки. Докато UCS-2 може да ги съхранява, но не и да ги интерпретира, както UTF-16, така и UTF-32 могат да картографират всички Unicode кодови точки, точно както UTF-8.

Това може да е вярно, но е напълно без значение от оперативна гледна точка.

Отново вярно, но напълно без значение, тъй като UTF-16 и UTF-32 също картографират всички Unicode кодови точки.

В зависимост от обстоятелствата това може да е вярно и правилно сте загрижени за такава разточителна употреба. Въпреки това, както споменах във въпроса, който води до този ( Поддръжка на UTF-8, SQL Server 2012 и UTF8String UDT ), имате няколко опции за намаляване на загубеното пространство, ако повечето редове могат да се поберат в VARCHAR все пак някои трябва да са NVARCHAR . Най-добрият вариант е да активирате КОМПРЕСИЯ НА РЕД или КОМПРЕСИЯ НА СТРАНИЦА (само за Enterprise Editon!). Започвайки от SQL Server 2008 R2, те позволяват не-MAX NVARCHAR полета, за да използвате "Стандартна схема за компресиране за Unicode", която е поне толкова добра, колкото UTF-8, а в някои случаи е дори по-добра от UTF-8. NVARCHAR(MAX) полетата не могат да използват това фантастично компресиране , но техните данни IN ROW могат да се възползват от редовно компресиране на ROW и/или PAGE. Моля, вижте следното за описание на това компресиране и диаграма, сравняваща размерите на данните за:необработен UCS-2 / UTF-16, UTF-8 и UCS-2 / UTF-16 с активирано компресиране на данни.

SQL Server 2008 R2 - UCS2 компресия какво е това - Въздействие върху SAP системите

Моля, вижте и страницата на MSDN за Компресиране на данни за повече подробности, тъй като има някои ограничения (освен това, че е налично само в Enterprise Edition -- НО е достъпно за всички издания, започващи с SQL Server 2016, SP1 !!) и някои обстоятелства, при които компресията може да влоши нещата.

Верността на това твърдение зависи от това как се дефинира "диск". Ако говорите по отношение на обикновени части, които можете да закупите от рафта в магазин за използване във вашия настолен/лаптоп, тогава със сигурност. Но ако говорим от гледна точка на хранилище на корпоративно ниво, което ще се използва за вашите производствени системи, тогава се забавлявайте, обяснявайки на всеки, който контролира бюджета, че не трябва да отхвърля SAN за милиони долари, който искате, защото е „евтин ";-).

Никой, за който мога да се сетя. Е, стига да не следвате никакви ужасни съвети да направите нещо като внедряване на този UDT или преобразуване на всички низове в VARBINARY или чрез NVARCHAR(MAX) за всички низови полета;-). Но от всички неща, за които можете да се тревожите, SQL Server, използващ UCS-2 / UTF-16, не трябва да е едно от тях.

Но ако по някаква причина проблемът с липсата на собствена поддръжка за UTF-8 е изключително важен, тогава може да се наложи да намерите друга RDBMS, която да позволява UTF-8.

АКТУАЛИЗАЦИЯ 2018-10-02

Въпреки че това все още не е жизнеспособна опция, SQL Server 2019 въвежда собствена поддръжка за UTF-8 в VARCHAR / CHAR типове данни. В момента има твърде много грешки в него, за да може да се използва, но ако бъдат коригирани, това е опция за някои сценарии. Моля, вижте публикацията ми, "Нативна поддръжка на UTF-8 в SQL Server 2019:Спасител или фалшив пророк? “, за подробен анализ на тази нова функция.