Przechowywanie i wydajność skutki Unicode
SQL Server przechowuje dane Unicode przy użyciu schematu kodowania UCS-2.W ramach tego mechanizmu wszystkie znaki Unicode są przechowywane przy użyciu 2 bajtów.
Różnica w przechowywaniu danych znakowych między Unicode i innych niż Unicode zależy od tego, czy są przechowywane dane inne niż Unicode przy użyciu zestawów znaków dwubajtowych.Wszystkie języki azjatyckie Wschód i języka tajlandzkiego przechowywać znaków innych niż Unicode w pojedynczym bajtów.Dlatego przechowywania tych języków jako Unicode użyje dwa razy miejsca używanego określanie strona kodowa nie obsługujących kodu Unicode.Z drugiej strony strony kodowe nieobsługujących kodu Unicode wiele języków azjatyckich określ znak składowania w zestawach znaków zestaw zestaw znaków dwubajtowych (zestaw znaków dwubajtowych).Dla tych języków jest więc prawie nie różnica w magazynie innym niż Unicode i Unicode.
W poniższej tabela przedstawiono inne niż Unicode określ znak przechowywania danych w zestawach znaków dwubajtowych stron kodowych.
Język |
Strona kodowa |
|---|---|
Chiński (uproszczony) |
936 |
Chiński (tradycyjny) |
950 |
Japoński |
932 |
Koreański |
949 |
Wpływ na wydajność danych Unicode jest skomplikowany różnych czynników, które są następujące:
Różnica między reguły sortowania Unicode i reguły sortowania nieobsługujących kodu Unicode
Różnica między sortowania znaków dwubajtowych i jednobajtowe
Kod strona konwersji między klient i serwera
SQL Server wykonuje ciąg porównań danych innym niż Unicode zdefiniowana z sortowanie systemu Windows przy użyciu reguły sortowania Unicode.Ponieważ zasady te są znacznie bardziej skomplikowane niż reguły sortowania nieobsługujących kodu Unicode, są one więcej zasób-intensywnego.Tak Chociaż reguły sortowanie Unicode są często droższe, jest zazwyczaj mała różnica wydajności dane Unicode i innych niż Unicode zdefiniowane za pomocą sortowanie systemu Windows.
Jedynym przypadek , kiedy program SQL Server używa reguły sortowanie nieobsługujących kodu Unicode jest na danych innym niż Unicode jest zdefiniowany za pomocą sortowanie bazy danych SQL.Sortuje i skanowania, w tym wystąpienie są generalnie szybsze niż kiedy zastosowanie reguł sortowania Unicode.Reguły sortowania Unicode stosuje się do wszystkich danych Unicode, zdefiniowane przy użyciu sortowanie systemu Windows lub sortowania bazy danych SQL.
Drugorzędne znaczenie sortowania dużej ilości danych Unicode może być wolniejsze niż dane nieobsługujących kodu Unicode, ponieważ dane są przechowywane w podwójne bajty.Z drugiej strony, sortowanie azjatyckich znaków Unicode jest szybsze niż sortowanie danych zestaw znaków dwubajtowych azjatyckich w określonym strona kodowa, ponieważ dane zestaw znaków dwubajtowych jest faktycznie mieszaniną szerokości jednobajtowych i zestaw zestaw znaków dwubajtowych znaków Unicode są stałej szerokości.
Inne problemy z wydajnością przede wszystkim są określane poprzez wydanie Konwersja kodowania mechanizm między wystąpienie programu SQL Server i klient.Ogólnie rzecz biorąc wpływ na wydajność konwersji strona kodowej klient i serwera są nieistotne.Niemniej jednak należy zrozumieć, jakie występuje w tej warstwie.
Interfejsu API ODBC, 3.6 lub starszych wersja i API biblioteki DB nie rozpoznają Unicode.Dla klient używających metody dostępu do danych określonych przez te interfejsy API zasoby są używane niejawnie konwertować dane Unicode strona kodowa klient.Ponadto istnieje ryzyko uszkodzenie danych po stronie klient, gdy strona kodowa klient nie rozpoznaje niektórych znaków Unicode.
Nowsze wersje ODBC, począwszy od programu Microsoft Data Access Components wersja 2.7, który został dołączony do programu SQL Server w wersji 7.0 i OLE DB i ADO są świadomi Unicode i przyjąć mechanizm kodowania UCS-2.Dlatego jeśli aplikacja jest włączone Unicode, brak konwersji problemów podczas pracy ściśle z danych Unicode z wystąpienie programu SQL Server.Jeśli klient korzysta z interfejsu API obsługuje standard Unicode ale mechanizm przechowywania danych w wystąpienie programu SQL Server nie jest Unicode, nie ma żadnych problemów konwersji.Jednakże istnieje ryzyko, że wszelkie dane wstawić lub operacje aktualizacji zostanie uszkodzony, jeśli punktów kodowych dowolny znak nie może być mapowane do SQL Server stronę kodową.
Najważniejsze wskazówki dotyczące Unicode
Decydowania, czy do przechowywania danych innych niż zestaw znaków dwubajtowych ogólnie określone Unicode przez świadomość skutków w magazynie i jaka sortowanie, konwersji i uszkodzenie danych może się zdarzyć podczas klient interakcji z danymi.Sortowanie i konwersji mogą wpływać na wydajność, w zależności od tego, gdzie występuje.Dla większości aplikacji nieistotne jest efekt.Bazy danych z dobrze indeksy są szczególnie nie wpływają.Jednak uszkodzenie danych wpływa nie tylko integralność aplikacji i bazy danych, ale również firmy jako całości.Uwzględniając ten kompromis przechowywania danych znaków strona kodowa określonego może sensu, jeśli są spełnione oba następujące:
Oszczędność miejsca jest problem z powodu ograniczeń sprzętowych.Lub wykonywania częstych sortuje partii danych i badania wskazuje, że mechanizm przechowywania Unicode poważnie wpływa na wydajność.
Masz pewność, że pasował do Twojego stron kodowych wszystkich klientów uzyskujących dostęp do danych i że sytuacja ta nie spowoduje nieoczekiwane zmiany.
Większość z czas, decyzji do przechowywania danych znakowych, nawet bez zestaw znaków dwubajtowych danych w formacie Unicode powinny być bardziej oparte na potrzeby biznesowe, zamiast wydajności.W globalnej gospodarce popierane przez gwałtownego wzrostu ruchu w Internecie, jest się coraz ważniejsze niż kiedykolwiek do obsługi klient komputerach z różnymi ustawieniami regionalnymi.Ponadto on staje się coraz trudniejsze do pobrania z jednej strona kodowa obsługujący wszystkich znaków wymaganych przez odbiorców z całego świata.