Przechowywanie i efekty wydajności Unicode
SQL Server przechowuje dane w standardzie Unicode za pomocą schematu kodowania UCS-2.W obszarze tego mechanizmu wszystkie znaki Unicode są przechowywane przy użyciu 2 bajty.
Różnica do przechowywania danych znakowych między Unicode i nie obsługujących kodu Unicode, zależy od tego, czy dane nie obsługujących kodu Unicode są przechowywane przy użyciu zestawów znaków dwubajtowych.Wszystkich języków Azji Wschodniej i języka tajskiego znaków Unicode nie są przechowywane w pojedynczych bajtów.Dlatego przechowywania tych języków w standardzie Unicode używa służy strona kodowa nie obsługujących kodu Unicode określający miejsce dwa razy.Z drugiej strony kodowe nie obsługujących kodu Unicode, wiele innych języków azjatyckich określić magazynowania znaku w zestawach znaków zestaw zestaw znaków dwubajtowych (zestaw znaków dwubajtowych).Dlatego dla tych języków jest prawie nie różnicę w magazynie innym niż Unicode i Unicode.
W poniższej tabela przedstawiono określ znak przechowywania danych w zestawach znaków dwubajtowych stron kodowych nie obsługujących kodu Unicode.
Język |
Strona kodowa |
|---|---|
Chiński uproszczony |
936 |
Chiński tradycyjny |
950 |
Japanese |
932 |
Koreański |
949 |
Wpływ danych standardu Unicode na wydajność jest skomplikowanym w wielu różnych czynników, które mogą być następujące:
Różnica między reguły sortowania Unicode i reguły sortowania, innym niż Unicode
Różnica między sortowania znaków dwubajtowych i jednobajtowe
Kod konwersji strona między klient a serwerem
Program SQL Server powoduje wykonanie porównania ciągów danych nie obsługujących kodu Unicode zdefiniować za pomocą sortowanie systemu Windows przy użyciu reguły sortowanie Unicode.Ponieważ zasady te są znacznie bardziej skomplikowane niż reguły sortowania nie obsługujących kodu Unicode, są one bardziej obciąża.Tak reguły sortowanie Unicode są często droższe, są zazwyczaj niewielkie wydajności między danych Unicode i dane nie obsługujących kodu Unicode zdefiniowane za pomocą sortowanie systemu Windows.
przypadek tylko wtedy, gdy program SQL Server używa reguły sortowanie nie obsługujących kodu Unicode znajduje się na danych nie obsługujących kodu Unicode, które zdefiniowano za pomocą sortowanie bazy danych SQL.Sortuje i skanowanie w tym wystąpienie są generalnie szybsze od kiedy stosować reguły sortowania Unicode.Reguły sortowanie Unicode są stosowane do wszystkich danych Unicode, zdefiniowane za pomocą sortowanie systemu Windows lub sortowanie bazy danych SQL.
O drugorzędnym znaczeniu sortowania dużej ilości danych Unicode może być wolniejsze niż dane nie obsługujących kodu Unicode, ponieważ dane są przechowywane w podwójne bajty.Z drugiej strony, sortowanie znaków azjatyckich w standardzie Unicode jest szybsze niż sortowanie danych DBCS azjatyckich w określonym strona kodowa, ponieważ zestaw zestaw znaków dwubajtowych danych jest faktycznie mieszaniną jednobajtowe i dwubajtowe szerokości, znaki Unicode są stałej szerokości.
Inne problemy z wydajnością przede wszystkim są określane przez wydanie Konwersja kodowania mechanizm między wystąpienie serwera SQL a klient.Ogólnie rzecz biorąc wpływ na wydajność konwersji strona kodowej klient/serwer, są nieznaczne.Niemniej jednak należy wiedzieć, co ma miejsce w tej warstwie.
Interfejsu API ODBC w wersja 3.6 lub starszej i API biblioteki DB nie rozpoznają Unicode.Klienci, którzy korzystają z określonych przez te interfejsy API metody dostępu do danych zasoby są używane do strona kodowa klient niejawnie przekonwertować dane Unicode.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 program SQL Server w wersja 7.0 i OLE DB i obiektów ADO są świadomi Unicode i odpowiada za mechanizm kodowania UCS-2.Dlatego jeśli aplikacja jest włączone Unicode, brak konwersji problemów podczas pracy wyłącznie z danych Unicode z wystąpienie programu SQL Server.Jeśli klient korzysta z interfejsu API obsługujących kodu Unicode, ale mechanizm przechowywania danych w wystąpieniu programu SQL Server nie jest kodowana w standardzie Unicode, nie istnieją żadne problemy przy konwersji.Jednak istnieje ryzyko, że wszystkie dane wstawić lub aktualizacji operacji będzie jest uszkodzony, jeśli punktów kodowych dla dowolnego znaku nie mogą być mapowane do strona kodowa programu SQL Server.
Najważniejsze wskazówki dotyczące standardu Unicode
Decydowanie, czy do przechowywania danych innych niż znaków zestaw zestaw znaków dwubajtowych, Unicode jest zwykle oznaczona za pomocą świadomość skutków w magazynie i jaka sortowanie, konwersji i uszkodzenie danych możliwe może się zdarzyć podczas klient interakcji z danymi.Sortowanie i konwersji mogą wpłynąć na wydajność, w zależności od tego, gdzie on występuje.Jednak w przypadku większości aplikacji efekt jest nieistotna.Bazy danych z dobrze indeksy są szczególnie prawdopodobne, aby mieć wpływ.Jednak uszkodzenie danych wpływa nie tylko integralność aplikacji bazy danych, a także firmy jako całości.Biorąc pod uwagę tę zależność, przechowywanie danych znakowych w określonym strona kodowa może sensu, jeśli są spełnione oba z następujących czynności:
Oszczędzanie miejsca do magazynowania jest problemem, z powodu ograniczeń sprzętowych.Można także wykonywania częstych sortuje dużej ilości danych i testowanie wskazuje, że mechanizm magazynowania Unicode znacznie wpływa na wydajność.
Masz pewność, że stron kodowych wszystkich klientów dostępu do danych tej etykiety odpowiada układowi i rozmiarowi etykiety, którą posiadasz, i że taka sytuacja nie nieoczekiwanie zmienia się.
W większości przypadków decyzja do przechowywania danych znakowych, nawet bez znaków zestaw zestaw znaków dwubajtowych danych w standardzie Unicode należy oprzeć bardziej na potrzeby biznesowe zamiast wydajności.W globalnej gospodarki zaleca się przez szybki wzrost ruchu w Internecie to staje się ważniejsze niż kiedykolwiek, aby obsługiwać komputery klienckie, które są uruchomione inne ustawienia regionalne.Ponadto on staje się coraz bardziej trudne do pobrania strona jeden kod obsługujący wszystkich znaków wymaganych przez odbiorców na całym świecie.