W przeciwieństwie do niektórych innych RDBMS, które pozwalają na wybór kodowania, SQL Server przechowuje dane Unicode tylko w UTF-16 (Little Endian) i dane inne niż Unicode w 8-bitowym kodowaniu (rozszerzone ASCII, DBCS lub EBCDIC) dla dowolnej strony kodowej wynikającej z sortowania pola.
Ich decyzja o wybraniu UCS-2 ma sens, biorąc pod uwagę, że UTF-16 został wprowadzony w połowie 1996 r. i został w pełni określony w 2000 r. Wiele innych systemów również go używa (lub używa) (patrz:https://en.wikipedia.org/wiki/UTF-16#Użytkowanie ). Ich decyzja o kontynuowaniu z tym może być bardziej wątpliwe, choć prawdopodobnie jest to spowodowane tym, że Windows i .NET są UTF-16. Fizyczny układ bajtów jest taki sam w UCS-2 i UTF-16, więc aktualizacja systemów z UCS-2 do obsługi UTF-16 powinna być czysto funkcjonalna, bez konieczności zmiany jakichkolwiek istniejących danych.
Yyy ... nie. Tworzenie niestandardowego typu zdefiniowanego przez użytkownika za pomocą SQLCLR nie , w jakikolwiek sposób zapewni Ci zamiennik dowolnego typu natywnego. Jest to bardzo przydatne przy tworzeniu czegoś do obsługi specjalistycznych danych. Ale łańcuchy, nawet o innym kodowaniu, są dalekie od specjalizacji. Podążanie tą trasą dla danych ciągów zniszczyłoby jakąkolwiek użyteczność systemu, nie wspominając o wydajności, ponieważ nie byłoby możliwe użycie żadnego wbudowane funkcje tekstowe. Gdybyś był w stanie zaoszczędzić cokolwiek na miejscu na dysku, te zyski zostałyby wymazane przez to, co stracisz na ogólnej wydajności. Przechowywanie UDT odbywa się poprzez serializację go do VARBINARY . Aby więc zrobić dowolne porównanie ciągów LUB sortowanie, poza porównaniem „binarnym” / „porządkowym”, musiałbyś przekonwertować wszystkie inne wartości, jedna po drugiej, z powrotem do UTF-8, aby następnie wykonać porównanie ciągów, które może uwzględniać różnice językowe.
Poza tym ta "dokumentacja" to tak naprawdę tylko przykładowy kod / dowód koncepcji. Kod został napisany w 2003 roku ( http://msftengprodsamples.codeplex.com/SourceControl/latest#Kilimanjaro_Trunk/Programmability/CLR/UTF8String/CS/UTF8String/Utf8String.cs ) dla SQL Server 2005. Widziałem skrypt do testowania funkcjonalności, ale nic związanego z wydajnością.
Tak, bardzo. Domyślnie obsługa wbudowanych funkcji dotyczy tylko UCS-2. Ale począwszy od programu SQL Server 2012, można uzyskać je do obsługi pełnego zestawu znaków UTF-16 (dobrze, od wersji Unicode 5 lub 6, w zależności od systemu operacyjnego i wersji .NET Framework) przy użyciu jednego z sortowań, które ma nazwę kończącą się na _SC (tj. Znaki uzupełniające).
Prawidłowy. UTF-16 i UCS-2 używają dwubajtowych punktów kodowych. Ale UTF-16 używa niektórych z nich parami (tj. Par zastępczych) do mapowania dodatkowych znaków. Punkty kodowe używane dla tych par są zarezerwowane do tego celu w UCS-2, a zatem nie są używane do mapowania na żadne użyteczne symbole. Dlatego możesz przechowywać dowolny znak Unicode w SQL Server i będzie on prawidłowo przechowywany i pobierany.
Prawidłowy, choć wprowadzający w błąd. Tak, UTF-8 ma zmienną szerokość, ale UTF-16 jest również nieznacznie zmienny, ponieważ wszystkie znaki uzupełniające składają się z dwóch dwubajtowych punktów kodowych. Stąd UTF-16 używa 2 lub 4 bajtów na symbol, chociaż UCS-2 zawsze ma 2 bajty. Ale to nie jest myląca część. To, co jest mylące, to implikacja, że żadne inne kodowanie Unicode nie jest w stanie zakodować wszystkich innych punktów kodowych. Podczas gdy UCS-2 może je przechowywać, ale nie interpretować, zarówno UTF-16, jak i UTF-32 mogą mapować wszystkie punkty kodowe Unicode, tak jak UTF-8.
Może to prawda, ale jest to całkowicie nieistotne z operacyjnego punktu widzenia.
Ponownie, prawda, ale całkowicie nieistotna, ponieważ UTF-16 i UTF-32 również mapują wszystkie punkty kodowe Unicode.
W zależności od okoliczności może to być prawdą i masz rację, że martwisz się takim marnotrawstwem. Jednak, jak wspomniałem w pytaniu, które prowadzi do tego ( Obsługa UTF-8, SQL Server 2012 i UTF8String UDT
), masz kilka opcji, aby zmniejszyć ilość marnowanego miejsca, jeśli większość wierszy mieści się w VARCHAR jednak niektóre muszą być NVARCHAR . Najlepszą opcją jest włączenie KOMPRESJI WIERSZY lub KOMPRESJI STRONY (tylko wersja Enterprise!). Począwszy od SQL Server 2008 R2, zezwalają na NVARCHAR inne niż MAX pola, aby użyć „Standardowego schematu kompresji dla Unicode”, który jest co najmniej tak dobry jak UTF-8, aw niektórych przypadkach jest nawet lepszy niż UTF-8. NVARCHAR(MAX) pola nie mogą używać tej wymyślnej kompresji , ale ich dane IN ROW mogą korzystać ze zwykłej kompresji ROW i/lub PAGE. Poniżej znajduje się opis tej kompresji i tabela porównująca rozmiary danych dla:surowych UCS-2 / UTF-16, UTF-8 i UCS-2 / UTF-16 z włączoną kompresją danych.
SQL Server 2008 R2 - Kompresja UCS2 co to jest - Wpływ na systemy SAP
Zobacz także stronę MSDN dotyczącą kompresji danych aby uzyskać więcej informacji, ponieważ istnieją pewne ograniczenia (poza tym, że jest dostępny tylko w wersji Enterprise – ALE udostępniony dla wszystkich edycje zaczynające się od SQL Server 2016, SP1 !!) i pewne okoliczności, w których kompresja może pogorszyć sytuację.
Wiarygodność tego stwierdzenia zależy od tego, jak się definiuje „dysk”. Jeśli mówisz o częściach towarowych, które możesz kupić z półki w sklepie do użytku w komputerze stacjonarnym / laptopie, to na pewno. Ale jeśli mówimy o pamięci masowej na poziomie przedsiębiorstwa, która będzie używana w systemach produkcyjnych, baw się dobrze wyjaśniając każdemu, kto kontroluje budżet, że nie powinien odrzucać sieci SAN za milion dolarów, której potrzebujesz, ponieważ jest „tani ";-).
Żadnego, o którym bym nie pomyślał. Cóż, o ile nie zastosujesz się do żadnej okropnej rady, aby zrobić coś takiego jak implementacja tego UDT lub przekonwertowanie wszystkich ciągów na VARBINARY lub używając NVARCHAR(MAX) dla wszystkich pól tekstowych;-). Ale ze wszystkich rzeczy, o które możesz się martwić, SQL Server używający UCS-2 / UTF-16 nie powinien być jedną z nich.
Ale jeśli z jakiegoś powodu problem braku natywnej obsługi UTF-8 jest bardzo ważny, może być konieczne znalezienie innego RDBMS do użycia, który pozwala na UTF-8.
AKTUALIZACJA 2018-10-02
Chociaż nie jest to jeszcze realna opcja, SQL Server 2019 wprowadza natywną obsługę UTF-8 w VARCHAR / CHAR typy danych. Obecnie jest w nim zbyt wiele błędów, aby można było z niego korzystać, ale jeśli zostaną naprawione, jest to opcja dla niektórych scenariusze. Zobacz mój post, „Natywna obsługa UTF-8 w SQL Server 2019:Savior czy False Prophet?
”, aby uzyskać szczegółową analizę tej nowej funkcji.
