Підтримка мов в СУБД Microsoft SQL Server 2005 (документація), Документація, Програмування, статті

Введення


В СУБД Microsoft SQL Server 2005 в повній мірі реалізована робота з кодуванням Юнікод та мовою XML, які з’явилися у версії SQL Server 2000. Їх підтримка розширена за рахунок нових потужних інструментів для розробки та роботи із запитами, що входять до складу SQL Server Management Studio і Business Intelligence Development Studio. Надійна робота з національними мовами робить SQL Server 2005 актуальним продуктом для роботи з базами даних і прикладної платформою, що забезпечує підтримку міжнародної взаємодії і багатомовних середовищ.


У цьому документі дається огляд цих можливостей в загальному контексті. Перераховуються можливості, пов’язані з вимогами міжнародної та багатомовної середовища, і пояснюється, як проектні рішення можуть впливати на різні аспекти функціонування проекту.


Примітка. Для відображення деяких знаків національних алфавітів в документі використовуються наступні шрифти: Arial Unicode MS, Latha, Mangal, PmingLiu, Gulim, SimSun і MS-Mincho. Відсутність цих шрифтів не накладає суттєвих обмежень на розуміння документа.


Підтримка Юнікоду в SQL Server 2005


В основі всіх засобів підтримки мов в SQL Server 2005 лежить підтримка кодування Юнікод.


Юнікод – це стандарт, створений консорціумом Unicode – організацією, що сприяє використанню єдиного набору символів для будь-яких мов. SQL Server 2005 підтримує стандарт Юнікод версії 3.2. Версія 3.01 стандарту ідентична кодуванні ISO-10646,-міжнародним стандартом, відповідному Юнікод по всіх кодовою позиціях.


Принцип роботи Юнікоду полягає в тому, що для кожного символу, незалежно від платформи, програми або мови, передбачена унікальна кодова позиція. Програма, що підтримує Юнікод, може обробляти дані на будь-якій мові. Оскільки кодування призначена для того, щоб охопити всі символи всіх мов світу, необхідність в різних кодових сторінках для роботи з різними наборами символів відпадає.


Оскільки всі використовують Юникод системи завжди використовують одні й ті ж двійкові послідовності, щоб представляти всі символи, не виникає проблем, пов’язаних з неправильним перетворенням символів при переході від однієї системи до іншої.


Найпростіший спосіб роботи з символьними даними в багатомовних базах даних полягає в тому, щоб завжди застосовувати засновані на Юникоде типи даних nchar, nvarchar і nvarchar(max), А не відповідні їм типи char, varchar і text, Що використовують інші кодування. Тоді кожен клієнт побачить в даних ті ж символи, що і всі інші клієнти. Якщо, крім того, всі програми, що працюють з багатомовними базами даних, використовуватимуть змінні в Юнікод, необхідності в перетворенні символів не виникатиме.


Примітка. Тип даних ntext в наступній версії Microsoft SQL Server підтримуватися не буде.


Слід відрізняти кодові позиції кодування Юнікод і подаються ними символи від гліфів, що використовуються для візуального уявлення. Стандарт ISO (ISO / IEC 9541-1) визначає гліф як “розпізнається абстрактний графічний символ, незалежний від конкретного графічного представлення “. Отже, символ не обов’язково буває представлений одним і тим же гліфом, а цей гліф не обов’язково повинен бути унікальний. Який гліф буде використаний для подання певного елемента коду або їх послідовності, визначається вибраним шрифтом.


Додаткові відомості див на веб-сайті консорціуму Unicode.


Кодування


Юникод встановлює відповідність між кодовими позиціями і символами, але не вказує, як дані будуть представлені в пам’яті, базі даних або на веб-сторінці. Саме тут вступає в дію кодування даних у форматі Юнікод. Для Юнікоду існує багато різних способів кодування. У більшості випадків можна просто вибрати використовує Юникод тип даних і не приділяти уваги цим подробиць. Проте важливо мати уявлення про кодування в наступних ситуаціях:



Стандарт Юнікод визначає кілька кодувань для єдиного набору символів – UTF-7, UTF-8, UTF-16 і UTF-32. У цьому розділі описані такі поширені кодування



Як правило, SQL Server зберігає символи Юнікоду за допомогою схеми кодування UCS-2. Проте багато клієнтів обробляють Юникод в інших схемах кодування, наприклад, UTF-8. Так часто буває у випадку веб-додатків. У додатках мовою Microsoft Visual Basic рядки обробляються у схемі кодування UCS-2. Тому немає необхідності описувати в явному вигляді перетворення схем кодування між додатками Visual Basic і примірником SQL Server.


XML-дані SQL Server 2005 кодує за допомогою Юнікоду (UTF-16). Щоб забезпечити такі можливості моделі XML, як порядок документа і рекурсивні структури, дані в стовпці типу xml зберігаються у внутрішньому форматі у вигляді великих двійкових об’єктів (BLOB). Тому XML-дані, одержувані від сервера, надходять в кодуванні UTF-16. Якщо додатком потрібні дані в іншому кодуванні, воно саме повинно виконати необхідні перетворення.


Кодування UTF-16 використовується завдяки своїй підтримці багатобайтових і чотирьохбайтові символів. Вона обробляється відповідно до побайтово протоколом. Ці властивості забезпечують зручність використання кодування UTF-16 для передачі даних між різними комп’ютерами, які використовують різні кодування і порядок байтів. Оскільки XML-дані зазвичай широко поширюються в мережах, має сенс дотримуватися прийнятої за замовчуванням для XML-даних кодування UTF-16 в базі даних і при їх експортуванні до клієнтів.


Кодування UCS-2


Кодування UCS-2 – попередник UTF-16. Вона відрізняється від UTF-16 тим, що являє собою кодування з фіксованою довжиною, в якій всі символи представлені у вигляді 16-бітових значень (2 байтів), і, отже, не підтримує додаткові символи. UCS-2 часто плутають з UTF-16, яка використовується для внутрішнього представлення тексту в операційних системах Microsoft Windows (Windows NT, Windows 2000, Windows XP і Windows CE), хоча можливості UCS-2 більш обмежені.


Для зберігання інформації в Юникоде в Microsoft SQL Server 2000 і Microsoft SQL Server 2005 використовується кодування UCS-2, що відводить для зберігання кожного символу два байти незалежно від самого символу. Тому латинська буква “A” обробляється так само, як кирилична “Ш”, єврейська “ламед” (м), тамільська знак “Rra” (?) Або знак японської хірагани “E” (, |). Кожному з таких символів відповідає унікальний кодова позиція (для перерахованих це U +0041, U +0248, U +05 DC, U +0 BB1 і U +3048 відповідно, причому кожне четирехразрядном шістнадцяткове число представляє два байта кодування UCS-2).


Оскільки за допомогою кодування UCS-2 можна закодувати тільки 65 536 різних кодових позицій, сама по собі вона не дозволяє користуватися додатковими символами і сприймає їх як пари не визначених в Юникоде символів-заступників (сурогатів), що визначають додатковий символ в поєднанні один з одним. Однак SQL Server може зберігати додаткові символи без ризику їх втрати чи пошкодження. Розширити можливості SQL Server, забезпечивши його роботу з сурогатними парами, можна шляхом створення власних функції середовища CLR. Додаткові відомості про роботу з сурогатними парами і додатковими символами см. в розділі “Додаткові символи і сурогатні пари” нижче.


Примітка. Додатковий символ визначається як символ у кодуванні Юнікод, має додаткову кодову позицію. Додаткові кодові позиції знаходяться в діапазоні від U +10000 до U +10 FFFF.


Кодування UTF-8


Кодування UTF-8 являє собою схему кодування, призначену для обробки даних в форматі Юнікод, причому кодування здійснюється способом, що не залежать від порядку проходження байтів на конкретному комп’ютері. Ця кодування корисна при роботі з системами на основі кодування ASCII та іншими системами, орієнтованими на побайтовую обробку, для яких потрібні 8-бітові кодування. До числа таких систем відносяться поштові сервери, які повинні обслуговувати велику кількість комп’ютерів з різним порядком байтів, що використовують різні кодування і різні мови. Хоча SQL Server 2005 не зберігає дані у форматі UTF-8, він підтримує це кодування при обробці XML-даних. Додаткові відомості див Підтримка XML в SQL Server 2005 нижче в цьому документі.


Інші системи управління базами даних, такі як Oracle і Sybase SQL Server, забезпечують підтримку Юнікоду, використовуючи зберігання в форматі UTF-8. В залежності від реалізації сервера це може виявитися більш легко здійсненним рішенням для ядра бази даних, оскільки не потребують значних змін існуючого на сервері коду, що забезпечує обробку тексту, для побайтовой роботи з даними. Однак в середовищі Windows зберігання в форматі UTF-8 має кілька недоліків.



Незважаючи на ці витрати, а також з урахуванням того, що формат XML завоював серйозні позиції як стандарт обміну інформацією в Інтернеті, використання кодування UTF-8 за замовчуванням може бути корисним.


Примітка. Попередні версії СУБД Oracle і мови Java також використовують формат UCS-2 і не здатні розпізнавати сурогатні символи. Корпорація Oracle ввела підтримку Юнікоду в якості набору символів для баз даних починаючи з версії Oracle 7. В даний час СУБД Oracle підтримує два методи зберігання даних в форматі Юнікод: перший – кодування UTF-8 для символьних типів даних CHAR і VARCHAR2 і для всіх імен та літералів SQL, другий – кодування UTF-16 для зберігання типів даних Юникод NCHAR, NVARCHAR і NCLOB. СУБД Oracle дозволяє використовувати обидва методи одночасно.


Кодування UTF-16


UTF-16 прийнята в якості стандартної кодування в корпорації Майкрософт. Вона розширює можливості ОС Windows для кодування додаткових 1048576 символів. Потреба в діапазоні сурогатний символів назріла ще до публікації стандарту Юнікод 2.0, оскільки стало ясно, що досягти переслідуваної при розробці Юнікоду мети – забезпечити окрему кодову позицію для кожного символу кожного з мов, – Використовуючи тільки 65 536 символів, неможливо. Так, для деяких мов, наприклад китайської, для кодування історичних і літературних ідеограм, які, хоча і рідко використовуються, важливі у видавничій та наукової діяльності, було б потрібно використовувати всі можливі символи цього діапазону. У наступному розділі діапазон символів-сурогатів описаний більш докладно.


У кодуванні UTF-16, як і в UCS-2, відповідно до загального правила для ОС Windows використовується прямий порядок проходження байтів. Прямий порядок (на відміну від зворотного) означає, що молодший байт зберігається в пам’яті по молодшому адресою. Порядок байт має значення на рівні операційної системи. Подібно до інших програм, що виконуються на платформі Windows, SQL Server використовує прямий порядок байтів. Таким чином, шістнадцяткове слово, наприклад 0x1234, зберігається в пам’яті у вигляді 0x34 0x12. В деяких випадках, щоб правильно прочитати кодування символу, буває необхідно міняти порядок байт явним чином. До складу служб SQL Server Integration Services входять функції зміни порядку байтів тексту у форматі Юнікод. Додаткові відомості див Служби SQL Server 2005 Integration Services цього документа.


Додаткові символи і сурогатні пари


Зазвичай для подання символьних даних ОС Microsoft Windows використовує кодування UTF-16. Використання 16 бітів дозволяє представити 65536 унікальних символів. Проте навіть цього числа недостатньо, щоб охопити всі символи людських мов. У кодуванні UTF-16 певні кодові позиції використовують інші позиції, наступні безпосередньо за першими двома байтами, щоб визначити символи в діапазоні сурогатів.


Стандарт Юнікод включає 16 площин символів, що дозволяють визначити 1114112 знаків. Площина 0, або Базова багатомовна площину (Basic Multilingual Plane, BMP), може представляти більшість писемностей світу, символів, що використовуються у видавничій справі, математичних і технічних символів, знаки пунктуації, геометричні форми і всі піктограми шрифта Zapf Dingbats рівня 100.


За межами площини BMP символи, що входять у більшість площин, як і раніше не визначені, але можуть використовуватися для подання додаткових символів. Додаткові символи використовуються в основному для історичних документів і творів класичної літератури, щоб забезпечити кодування багатого літературної спадщини, що існує на китайській, корейській та японській мовах. Сюди також входять руни та інші історично використовувалися види листи, музичні символи тощо.


У кодуванні UTF-16 для представлення символів, що не входять в основний набір символів (BMP) використовується пара кодових позицій, звана сурогатної парою. Область символів-сурогатів – діапазон Юнікоду від U + D800 до U + DFFF, що включає 1024 молодших значень сурогатів і 1024 старших. Старший сурогат (в діапазоні від U + D800 до U + DBFF) і молодший (від U + DC00 до U + DFFF) об’єднуються, що забезпечує можливість доступу до більш ніж мільйону можливих символів.


Половина сурогатної пари не вважається дійсною. Дійсна сурогатна пара завжди повинна бути послідовністю старшого символу-сурогату, за яким слід молодший. Це зводить перевірку того, чи належить символ до числа сурогатів, до перевірки потрапляння в діапазон, що набагато простіше системи правил, необхідної для розпізнання DBCS (двобайтового системи символів).


Як SQL Server 2000, так і SQL Server 2005 можуть зберігати сурогатні пари, незважаючи на те, що кодування UCS-2 не передбачає їх. SQL Server обробляє такі пари як два невизначених символу Юнікод, а не як один символ. Зазвичай подібні додатки називають нейтральними до суррогатам або безпечними по відношенню до суррогатам, маючи на увазі, що вони не мають вбудованої здатністю взаємодіяти з такими даними, але, принаймні, можуть зберігати їх без втрат.


Підтримуючі сурогати програми, навпаки, не тільки враховують наявність сурогатних пар, але, крім того, здатні обробляти несамостійні символи та інші символи, що вимагають спеціальної обробки. Добре написаний додаток може розпізнавати розділені сурогати і возз’єднати їх за допомогою всього декількох підпрограм. Серед підтримують сурогати програм – текстовий редактор Microsoft Word і веб-браузер Internet Explorer 5 і пізніших версій.


При роботі з додатковими символами в SQL Server слід враховувати наступні обставини.



Несамостійні символи


Несамостійні символи є символи, які використовуються спільно з іншими символами для зміни виду або значення останніх. Об’єднані, вони утворюють єдиний гліф. Наприклад, діакритичні знаки в європейських мовах – це несамостійні символи. Діакритики може представлятися у вигляді або послідовності звичайного символу і несамостійного, або складеного символу.


У платформі. NET Framework послідовність несамостійних символів обробляється як елемент тексту – тобто, як одиниця тексту, що відображається у вигляді єдиного символу. Елемент тексту не тотожний елементу сортування. Наприклад, для деяких параметрів букви “CH” не є несамостійними символами. Вони являють собою два окремих елемента тексту, але можуть розглядатися як один елемент сортування.


Примітка. Функції SQL, навпаки, зазвичай обробляють несамостійні символи так само, як додаткові символи – як дві окремих кодових позиції Юнікоду.

Відповідність між несамостійними символами та елементами сортування залежить як від стандарту Юнікод, так і від параметрів сортування. Деякі несамостійні символи завжди вважаються еквівалентними всім своїм варіантами незалежно від того, скільки кодових позицій ті включають (наприклад, латинська літера “a” з акцентованого знаком розглядається як еквівалент складного символу, вже включає такий же діакритичний знак), тоді як при деяких параметрах сортування можна сортувати або порівнювати рядки по-різному в залежності від того, чи присутній у них діакритики.


Вперше несамостійні символи були визначені в стандарті Юнікод 2.0. Додаткові відомості див специфікації Юнікоду 4.0.1, Присвяченому спеціальним областям і символам форматування. Консорціум Unicode публікує також “питання і відповіді” (FAQ), присвячені несамостійним символам та їх обробки.


Підтримка стандарту GB18030


GB18030 (GB18030-2000) – це окремий стандарт, який Китайською народною республікою (КНР) пропонується використовувати для кодування китайських символів. Він встановлює як розширену кодову сторінку, так і таблицю зіставлення символам Юнікоду. На 1 серпня 2006 р. офіційно потрібно, щоб всі програмні продукти, що продаються в КНР, підтримували цей набір символів. Відповідність стандарту GB18030 увазі також наявність підтримки деяких раніше не підтримується мов, наприклад тибетського, монгольського, іцзу і уйгурського.


У кодуванні GB18030 символи можуть бути довжиною 1, 2 або 4 байти. Щоб забезпечити зіставлення 4-байтних послідовностей GB18030 кодування Юнікод, використовуються сурогатні пари.


SQL Server 2005 підтримує символи в кодуванні GB18030, розпізнаючи їх у момент надходження на сервер від програми на стороні клієнта. Вони перетворюються і зберігаються в стандартному для нього форматі Юнікод. Після того, як символи збережені на сервері, при будь-яких подальших операціях над ними вони обробляються як символи Юнікоду. Для кодування GB18030 не встановлено регіональних стандартів, передбачений лише ідентифікатор кодової сторінки, необхідний для перетворень в Юнікод і з нього. Ідентифікатор кодової сторінки для кодування GB18030-2000, прийнятий корпорацією Майкрософт, дорівнює 54936.


При використанні символів GB18030 слід пам’ятати, що їх можна використовувати в операціях упорядкування і порівняння, але при використанні параметрів сортування, що передували таким в SQL Server 90, проводяться тільки порівняння на підставі кодових позицій символів, і при цьому не використовуються ніякі інші лінгвістично значущі характеристики. Тому слід проявляти обережність при використанні символів GB18030 в таких операціях, як ORDER BY, GROUP BY і DISTINCT, особливо якщо в одній операції беруть участь і символи GB18030, і символи інших кодувань. Щоб зробити можливим осмислене порівняння рядків символів GB18030, використовуйте нові версії параметрів сортування SQL Server 90, позначені додаванням до їх імен суфікса “90”. Так, замість параметрів Chinese_PRC використовуйте Chinese_PRC_90.


Для включення підтримки стандарту GB18030 можна встановити пакет підтримки, який можна завантажити з порталу Довідки та підтримки продуктів корпорації Майкрософт, І який включає файл шрифту і бібліотеки, що підтримують перетворення між кодуваннями GB18030 і Юнікод. Пакет підтримки представляє собою єдиний двійковий файл у міжнародній версії, який здатний працювати під ОС Windows XP або Windows 2000. Однак у системі повинні бути встановлені засоби підтримки східно-азіатських мов. В ОС Windows Vista підтримка стандарту GB18030 включена спочатку. В ній є шрифти і розкладки клавіатури для таких мов китайських національних меншин, як тибетський, іцзу, монгольська і уйгурський. Для цих мов як регіонального стандарту встановлюється “Китайська (КНР)”.


Примітка. Деякі функції перетворення байт GB18030 в символи Юнікоду, наприклад BytesToUnicode, В ОС Vista не підтримуються. Для такого перетворення використовуйте функцію MultiByteToWideChar.


Типи даних в SQL Server 2005


У цьому розділі описані нові для SQL Server 2005 типи даних і порушені питання, пов’язані з використанням типів даних SQL Server 2005 для зберігання багатомовних даних.


Текстові типи, які не підтримують Юнікод: char, varchar, text, varchar (max)


При роботі з текстовими даними, які зберігаються у вигляді типів char, varchar, varchar(max) або text, Головне обмеження, яке слід враховувати, полягає в тому, що системою може бути перевірена інформація, що відноситься тільки до однієї кодової сторінки. (Зберігати дані, що належать до кількох кодовою сторінкам, не рекомендується, хоча і можливо.) Яка саме кодова сторінка буде використана для перевірки та зберігання даних, залежить від параметрів сортування стовпця. Якщо ці параметри на рівні стовпця не були визначені, буде використано параметри сортування бази даних. Для визначення кодової сторінки, яка буде використана для конкретного стовпця, можна використовувати функцію COLLATIONPROPERTY, як показано в наступному прикладі коду:


SELECT COLLATIONPROPERTY(“Chinese_PRC_Stroke_CI_AI_KS_WS”, “CodePage”)
936
SELECT COLLATIONPROPERTY(“Latin1_General_CI_AI”, “CodePage”)
1252
SELECT COLLATIONPROPERTY(“Hindi_CI_AI_WS”, “CodePage”)
0

Останній приклад повертає як кодової сторінки для хінді значення 0 (Юнікод). Приклад ілюструє той факт, що багатьом регіональним мовним стандартам, таким як грузинський і хінді, не відповідають кодові сторінки, оскільки ці мови мають параметри сортування тільки для Юнікоду. Такі параметри не підходять для стовпців, що використовують типи даних char, varchar або text, А деякі з параметрів були визнані застарілими.


Важливо! У SQL Server 2005 замість типу даних text слід використовувати varchar(max). Тип даних text не буде підтримуватися в наступній версії Microsoft SQL Server.

При необхідності вставити дані формату Юнікод в стовпці з іншими кодуваннями здійснюється внутрішнє перетворення стовпців з кодування Юнікод за допомогою функції WideCharToMultiByte і кодової сторінки, відповідної параметрам сортування. Якщо символ не може бути представлений за допомогою даної кодової сторінки, він замінюється знаком питання (?). Тому поява серед даних знаків питання у випадкових місцях служить хорошою ознакою того, що відбулося спотворення даних через невизначеного перетворення. Це також окреслить переваги, які отримала б додаток від переходу на роботу з даними в Юнікод.


Якщо використовується рядковий літерал не підтримуваного параметрами сортування типу, не використовує Юнікод, рядок спочатку перетвориться за допомогою кодової сторінки за замовчуванням для бази даних. Визначення цієї кодової сторінки здійснюється на підставі встановлених за замовчуванням параметрів сортування бази даних.


Інша проблема, яка може виникнути – неможливість зберігати дані у випадку, коли в кодовій сторінці містяться не всі символи, підтримку яких необхідно забезпечити .. У багатьох випадках Windows підбирає кодову сторінку, яка лише підходить найкращим чином, що означає відсутність гарантованої можливості обробити за її допомогою весь текст. Ця кодова сторінка – всього лише найкраща з тих, що є. Прикладом може служити арабський набір знаків. Він підтримує безліч мов, включаючи балучі, берберська, фарсі, кашмірський, казахська, киргизька, курдська, пушту, Сіндхі, уйгурська, урду та інші. У всіх цих мовах є додаткові символи крім символів арабської мови, що входять в кодову сторінку Windows 1256. При спробі зберегти ці додаткові символи у стовпці з кодуванням, відмінною від Юнікоду, і арабськими параметрами сортування, вони будуть перетворені в знаки питання.


Текстові типи, що підтримують Юнікод: nchar, nvarchar, nvarchar (max), ntext


Специфікація SQL-92 визначає типи даних, що починаються з “N” (буква позначає “національні” типи даних), але не наказує, щоб ці типи даних використовувалися для Юнікоду. Фактичне визначення цих типів залишено платформі бази даних або розробникам. У версіях SQL Server 2000 і SQL Server 2005 ці типи даних визначені як еквівалентні UCS-2, яка представляє собою кодування Юнікод. Однак при роботі з іншими серверами баз даних важливо знати, що типи даних, що починаються на “N”, не обов’язково передбачають використання Юнікоду. Визначення типів даних, які починаються на “N”, як використовують Юникод – це особливість СУБД Microsoft SQL Server.


Тип даних nvarchar(max), Що з’явився в SQL Server 2005, може містити до2 гігабайт (ГБ) даних. Це краща альтернатива типу даних ntext.


Важливо! У SQL Server 2005 замість типу даних ntext слід користуватися типом nvarchar(max). Тип даних ntext не буде підтримуватися в наступній версії Microsoft SQL Server.

При зберіганні складного листа, такого як хінді або тамільської мови, переконайтеся, що дані правильно впорядковані. Багато мови, наприклад тамільська, вимагають зміни порядку розташування певних символів при відображенні тексту. Тому логічний порядок тексту в тому вигляді, в якому він зберігається в пам’яті, може відрізнятися від порядку при візуальному представленні в інтерфейсі користувача. Для будь-яких мов зі складним листом, в число яких входять всі індоарійські мови, арабська, фарсі, іврит і багато інших, дані завжди повинні зберігатися в правильному логічному порядку. Реальне відображення таких даних – це окреме питання (див. розділ Багатомовні дані в інтерфейсі цього документа).


Хоча стовпці “N”-типів можуть підтримувати використання даних на будь-якій мові або поєднанні мов, при сортуванні даних можна вибрати тільки одні параметри сортування. Більш докладно це питання описується у розділі Параметри сортування цього документа. Ніякі із згаданих вище обмежень, пов’язаних з кодовими сторінками, не відносяться до стовпцях в Юнікод.


У SQL Server 2005 можна створювати додаткові функції, що дозволяють поліпшити обробку рядків і роботу параметрів сортування з додатковими символами. Так, зразок StringManipulate для SQL Server 2005 показує приклад обробки рядків з урахуванням додаткових символів. У ньому наводиться реалізація п’яти строкових функцій Transact-SQL. Нові функції забезпечують ті ж можливості обробки рядків, що і вбудовані, але поряд з рядками в Юникоде підтримують обробку рядків з додатковими символами.


Типи даних CLR


Microsoft SQL Server дає можливість розширити систему типів SQL, визначивши користувальницький тип даних, який можна використовувати в програмуванні для SQL Server. Ці визначені користувачем типи зручні для створення спеціальних типів дати, часу, валюти і розширених чисельних типів, а також для закодованих або зашифрованих даних.


Визначено користувачем тип (user-defined type, UDT) можна використовувати для визначення типу стовпця таблиці або ж змінних і параметрів процедур в мові Transact-SQL. Примірником такого типу може бути стовпець таблиці, змінна в пакеті, функція або процедура, що зберігається, а також аргумент функції або процедури, що зберігається. Визначено користувачем тип реалізується у вигляді керованого класу на будь-якому з мов CLR, а потім реєструється SQL Server.


Визначені користувачем типи використовуються для розширення системи скалярних типів даних сервера, що дозволяє зберігати в базі даних SQL Server об’єкти CLR. Ці типи можуть містити більше одного елемента і підтримувати певні користувачем особливі режими роботи. Це відрізняє їх від традиційних псевдонімів типів даних, які складаються з єдиного системного типу даних SQL Server. Наприклад, зразок Currency UDT, наведений в електронній документації по SQL Server 2005, підтримує обробку грошових сум у грошовій системі, пов’язаної з певною культурою. Ви повинні визначити два поля: значення типу string, CultureInfo, яке вказує країну валюти (наприклад en-us), і значення типу decimal, CurrencyValue, що зберігає суму.


Оскільки доступ до UDT здійснюється як до єдиного цілого, їх використання для складних типів даних може погано позначитися на продуктивності. Як правило, складні схеми даних легше піддаються моделюванню за допомогою традиційних рядків і таблиць. В електронну документацію по SQL Server 2005 входить кілька зразків, що показують, як створювати визначені користувачем типи і працювати з ними. Зразок UTF8String для SQL Server 2005 показує, як реалізувати визначений користувачем тип даних, що доповнює систему типів бази даних для того, щоб забезпечити зберігання значень в кодуванні UTF8. У новому типі також реалізований код для перетворення рядків Юнікоду в кодування UTF8 та назад.


Тип даних XML


Тип даних XML дозволяє зберігати в базах даних SQL Server фрагменти або документи формату XML. Екземплярами типу даних XML можуть бути стовпці таблиці, аргументи функцій і процедур, а також їх змінні. Крім того, можна зробити тип даних XML спеціалізованим, вказавши XML-схему, що забезпечує як обмеження при перевірці, так і інформацію про тип даних для примірника XML.


Дії над екземпляром типу даних XML можна здійснювати, використовуючи вбудовані методи для запитів до XML. Ці методи приймають запити та інструкції обробки, призначені для таких даних. Можна здійснювати запити (XQuery) до даних XML, що зберігається у змінній або стовпці типу даних XML, а також вносити до них зміни (за допомогою інструкцій insert, update і delete). Можна також використовувати схему XSD для створення індексу стовпця XML, що дозволить поліпшити продуктивність запитів.


Додаткові відомості про тип даних xml і засобах підтримки обробки даних XML в SQL Server 2005 див Підтримка XML в SQL Server 2005 цього документа.


Типи дати і часу: datetime, smalldatetime


Використовувані в SQL Server 2000 і SQL Server 2005 типи дати і часу визначені наступним чином:


datetime


Дата і час за григоріанським календарем в діапазоні від 1 січня 1753 до 31 грудня 9999 р. з точністю до однієї трьохсот частки секунди (що дорівнює 3,33 мілісекундах, або 0,00333 секундам).


smalldatetime


Дата і час за григоріанським календарем в діапазоні від 1 січня 1900 р. до 6 червня 2079 з точністю до однієї хвилини. Значення типу smalldatetime, Що закінчуються на 29,998 або меншу кількість секунд, округлюються до найближчої хвилини вниз, а значення, що закінчуються на 29,999 або більшу кількість секунд, округлюються до найближчої хвилини вгору.


Microsoft SQL Server відхиляє дані, що виходять за ці межі. Самі дані зберігаються у внутрішньому представленні у вигляді двох цілих чисел, що представляють відповідні дату і час (4-байтові цілі для типу datetime і 2-байтові для smalldatetime).


Збережені дані не вказують, чи належать вони до місцевого часу або до всесвітнього, і не містять інформації про часовий пояс. Якщо вам необхідно перевести дані в значення всесвітнього часу, можна використовувати одну з функцій часу UTC. Поточний час UTC визначається на підставі поточного місцевого часу і настройки часового поясу в операційній системі комп’ютера, на якому працює даний екземпляр Microsoft SQL Server. Оскільки значення не має власного форматування, відповідного регіональним стандартам, визначення необхідних перетворень лягає на розробника. SQL Server підтримує безліч відповідають різним мовам перетворень, які можуть здійснюватися на сервері і служать альтернативою власним рішенням розробників. До таких стилям дат можна звертатися за допомогою функції CONVERT, яка використовує як аргументи тип даних, вираз і, при необхідності, стиль з числа наведених у таблиці нижче.




















































































































З віком


Без століття


Стандартна схема


Введення (перетворення до типу datetime)
Висновок (перетворення в текст)

0 або 100 За замовчуванням міс дд гггг гг: мм AM (або PM)
101 1 США мм / дд / рр
102 2 ANSI гг.мм.дд
103 3 Британська / фарнцузская дд / мм / рр
104 4 Німецька дд.мм.гг
105 5 Італійська дд-мм-рр
106 6 дд міс рр.
107 7 Мес дд, мм
108 8 чч: мм: сс
9 або 109 За замовчуванням + мілісекунди міс дд гггг гг: мм: сс: ммм AM (або PM)
110 10 США мм-дд-рр
111 11 Японська рр / мм / дд
112 12 ISO ггммдд
13 або 113 Європейська за замовчуванням + мілісекунди дд міс гггг гг: мм: сс: ммм (24-годинний формат)
114 14 чч: мм: сс: ммм (24-годинний формат)
20 або 120 Канонічна для ODBC гггг-мм-дд гг: мм: сс (24-годинний формат)
21 або 121 Канонічна для ODBC + мілісекунди гггг-мм-дд гг: мм: сс: ммм (24-годинний формат)
126 ISO8601 (без пробілів) гггг-мм-дд Tчч: мм: сс: ммм
130 Кувейтська (хиджра) дд міс гггг гг: мм: сс: ммм AM (або PM)
131 Кувейтська (хиджра) дд / мм / рр гг: мм: сс: ммм AM (або PM)

Наступний приклад демонструє використання функції CONVERT для подання поточної дати в зазначеному стилі:


SELECT CONVERT(char, GETDATE(), 100) AS [100]
RETURNS:
Aug 16 2000 11:50AM

Подібним же чином можна перетворити дані з рядка в значення дати:


SELECT CONVERT(datetime, “Aug 16 2000 11:50AM”, 100) AS [100]
RETURNS:
100
2000-08-16 11:50:00.000

Якщо дати стилю 130 (Кувейт, хиджра) перетворюються в тип даних char, Вони можуть бути пошкоджені, якщо параметри сортування не відносяться до арабських, які використовують для перетворень Юнікоду кодову сторінку 1256. Наприклад, на рис. 1 показані стовпці, один з яких був перетворений в тип char, А другий – в тип nchar. У цьому прикладі клієнтський комп’ютер використовує як регіональних параметрів EN-US. Тому при спробі використовувати тип даних char арабські символи перетворяться в знаки питання, тоді як при використанні типу nchar вони відображаються правильно.


Рис. 3.Приклад двобічної рядки дати


Такий порядок при відображенні (дд гг: мм: сс гггг міс :), очевидно, не відповідає очікуваному. Цю проблему можна вважати загальним обмеженням стилю 130 при застосуванні функції CONVERT. Обхідним шляхом вирішення цієї проблеми може бути додавання потрібного керуючого символу Юнікод попереду рядки, як в наступному запиті:


SELECT NCHAR(8207) + CONVERT(nchar, GETDATE(), 130)

Функція NCHAR повертає символ на основі переданої їй кодової позиції Юнікоду. 8207, або шістнадцяткове 0x200F, являє собою маркер запису справа наліво (RLM), використання якого дозволяє відобразити рядок правильно.


Продуктивність і простір для зберігання


Якщо стовпець визначений як відноситься до одного з типів даних Юнікоду, можуть виникнути такі проблеми, пов’язані з простором для зберігання і швидкістю роботи.


Збільшення використовуваного простору для зберігання


У типах даних, що використовують Юникод, кожен символ кодується двома байтами або більше, в той час як не використовують Юникод типи даних представляють будь-який символ за допомогою одного байта, а символи азіатських мов в двобайтового кодуванні – за допомогою двох. Тому, якщо дані не використовують одну з азіатських кодових сторінок, при перетворенні в Юнікод для їх зберігання потрібно у два рази більше місця. Збільшення вимог до простору слід враховувати як при модернізації існуючих баз даних, так і при виборі відповідних типів даних для нового проекту. Якщо ви зберігаєте дані тільки в стовпці, використовує єдину (і не азіатську) кодову сторінку, можливо, має сенс відмовитися від використання Юнікоду для економії простору на диску і в пам’яті. Однак переваги, пов’язані з перетворенням даних в Юнікод, зазвичай переважують вплив цього перетворення на простір для зберігання.


Примітка. При зберіганні даних в азіатській двобайтового кодуванні використовується SQL Server 2005 метод кодування UCS-2 зазвичай виявляється більш ефективним, ніж метод UTF-8, що використовується багатьма іншими програмами для роботи з базами даних. Так відбувається тому, що в кодуванні UTF-8 на зберігання більшості знаків азіатських мов витрачається три байти, а в кодуванні UCS-2, за винятком додаткових і несамостійних символів, тільки два. З іншого боку, для мов, що не використовують багатобайтових кодування, наприклад мов на основі символів кодування ASCII, кодування UTF-8 звичайно використовує тільки по одному байту на символ, тоді як UCS-2 використовує два.


Вплив на швидкість


Вплив типів даних, що використовують Юнікод, на продуктивність має складний характер. Слід враховувати наступні аспекти.



Важливо! Для реалістичної оцінки продуктивності слід протестувати як варіант з використанням Юнікоду, так і варіант без нього.


Міграція метаданих системних таблиць


Системні таблиці в SQL Server 2005 зберігають всі знаходяться в них дані, включаючи ідентифікатори об’єктів, у форматі Юнікод. Це мінімізує небезпеки, які можуть виникнути, коли параметри сортування для баз даних і стовпців відрізняються.


При здійсненні міграції з SQL Server 2000 на SQL Server 2005, єдине значне зміна полягає в тому, що SQL Server 2000 для списку застосовних в ідентифікаторах символів використовує стандарт Юникод 2.0, тоді як SQL Server 2005 підтримує стандарт Юнікод версії 3.2.


Можливо безпосереднє оновлення примірників SQL Server 2000 з пакетом оновлень 3 (SP3) або більш пізніх версій, а також екземплярів SQL Server 7.0 з пакетом оновлень 4 (SP4) або більш пізніх версій до SQL Server 2005. Більшість операцій оновлення можна виконати за допомогою програми установки. Однак деякі компоненти вимагають міграції додатків і рішень після її виконання.


Параметри сортування


Порядок сортування – критично важлива частина визначення бази даних. Тим не менш, їй часто не приділяють достатньої уваги. Користувачі схильні сприймати сортування на основі звичного для них алфавіту як щось само собою зрозуміле. Однак для деяких мов, наприклад для грецького, російського і тайського, використовуються інші алфавіти. У деяких, наприклад, в японському, використовується кілька алфавітів і складні правила впорядкування. Навіть в європейських мовах існує безліч відмінностей в тому, як обробляються окремі символи. Наприклад, іспанські користувачі очікують, що поєднання букв “ch” при сортуванні буде сприйматися як єдина буква, наступна за буквою “h”.


Основна сортування використовує параметри сортування, які, поряд з іншими моментами, управляють порядком сортування. Сортування можна оптимізувати, створюючи індекси.


Сортування працює спільно з технікою, званої нормалізацією рядків. Такий вид нормалізації відрізняється від нормалізації в тому сенсі, до якого звикли розробники баз даних. Під нормалізацією рядків мається на увазі метод порівняння двох рядків таким чином, щоб їх можна було піддати сортуванню. Наприклад, можна вказати, чи слід розглядати різні типи кани як еквівалентні, або слід Чи ігнорувати діакритичні знаки.


Для стовпців, що не використовують Юникод, параметри сортування мають другу і дуже важливе значення – вони вказують кодову сторінку для даних і, тим самим, визначають, які символи можуть бути в ньому представлені. Між стовпцями, які використовують Юникод, дані можна переміщати без перетворення або зіставлення символів; дані, що переміщуються між стовпцями, не використовують Юнікод, часто виявляються пошкодженими або спотвореними – або, щонайменше, їх не вдається відобразити.


Параметри сортування в SQL Server 6.5 і більш ранніх версіях


У SQL Server версії 6.5 і раніших параметри сортування використовувалися для вказівки кодової сторінки, яку слід використовувати для мови в цілому. Існували численні обмеження, пов’язані з різними порядками сортування. Наприклад, підтримку західноєвропейських мов можна було забезпечити тільки при використанні сторінки Latin-1. Параметри сортування також обмежували кількість різних регіональних стандартів, які можна було уявити в одному примірнику SQL Server. Іншими словами, зберігати або відображати можна було тільки мову, що використовується в конкретному регіоні. Щоб використовувати іншу мову, було необхідно створити окрему базу даних або навіть окремий сервер.


Ці ж проблеми мають місце при роботі з не використовують Юникод полями в більш пізніх версіях SQL Server.


Параметри сортування в SQL Server 7.0


SQL Server 7.0 передбачав по одному режиму зіставлення для Юнікоду і одному – без використання Юнікоду для кожного сервера. Параметри сортування, які не використовують Юникод, визначалися як поєднання кодової сторінки і порядку сортування. Часто кожна кодова сторінка підтримує більше одного порядку сортування. Наприклад, романські мови зазвичай допускають сортування як з урахуванням, так і без урахування регістра. Спрощене китайське лист дозволяє сортування як по кількості штрихів, так і фонетичну.


Для параметрів сортування, що використовують Юнікод, в стовпець може бути включений будь-який символ будь-якої мови, а наявні різноманітні параметри сортування розроблені з урахуванням правильної обробки будь-яких відмінностей між собою. Іншими словами, ви вибираєте “найкраще відповідність”, щоб надати користувачам очікувані ними дані. Наприклад, загальні параметри сортування для Юнікоду дозволяють сортувати дані на фарсі.


Параметри сортування для Юнікоду складаються з регіонального стандарту і кількох стилів порівняння. Регіональним стандартам зазвичай даються назви країн або культурних областей. Символи сортуються відповідно зі стандартом, чинним в цій галузі. Параметри сортування для Юнікоду передбачають порядок сортування для всіх символів стандарту Юнікод, але перевага віддається вказаною регіонального стандарту. Для будь-якого регіонального стандарту, що не має підтримуваних унікальних параметрів сортування для Юнікоду, повинні використовуватися загальні параметри сортування Юнікоду.


Загальний порядок сортування Юнікоду забезпечує не тільки обробку даних, а й сортування таких мов: албанської, англійської, арабської, африкаанс, баскської, білоруського, болгарського, грецького, грузинського (традиційного), івриту, індонезійського, малайського, російської, сербської, суахілі, урду, фарерської, фарсі і хінді.


Важливим нововведенням в SQL Server 7.0 була незалежна від операційної системи модель порівняння рядків, що забезпечувала единообразность параметрів сортування для всіх ОС від Windows 95 до Windows 2000. Цей код порівняння рядків був заснований на тому ж коді, який використовує для нормалізації рядків сама ОС Windows 2000. Він инкапсулирован для забезпечення єдності поведінки на всіх комп’ютерах і у всіх версіях SQL Server.


Параметри сортування в SQL Server 2000


В СУБД SQL Server 2000 модель сортування була змінена, щоб виключити невідповідності між різними системами сортування – Windows і SQL Server Для задоволення всіх виниклих вимог до параметрів сортування потрібна була більш гнучка модель. Нові параметри сортування в SQL Server 2000 були потрібні також для роботи з кодовою сторінкою стовпців, в яких не використовується формат Юнікод.


У зв’язку з цим була розроблена єдина, узгоджена модель, що дозволяє виконувати сортування як у форматі Юнікод, так і в інших кодуваннях. Кожен набір параметрів сортування був забезпечений суфіксами, дозволяють визначити, чи враховуються при сортуванні регістр, діакритичні знаки, ширина або тип кани. В Додатку A наведена таблиця, в якій перераховані такі суфікси. Ці 17 суфіксів в поєднанні з 40 підтримуваними SQL Server 2000 мовами дають 680 наборів параметрів сортування Windows.


Назви мов, якими були позначені параметри сортування, були вибрані довільно. Вони повинні були представляти кожну з унікальних підтримуваних кодових сторінок для даних в кодуваннях, відмінних від Юнікоду, а також порядок сортування для всіх даних. У багатьох випадках одна кодова сторінка являє декілька мов, або ж вони можуть оброблятися за допомогою порядку сортування, використовуваного для іншої мови. У цих випадках додаткові мови були виключені зі списку.


Параметри сортування в SQL Server 2005


СУБД SQL Server 2005 підтримує всі мови, які підтримуються операційними системами Microsoft Windows. Це означає, що в SQL Server 2005 була додана підтримка параметрів сортування, вперше з’явилися або оновлених в Windows Server 2003 і Windows XP. (Ці параметри сортування задаються під час встановлення SQL Server 2005. Вибір параметрів сортування для сервера і бази даних здійснюється під час їх налаштування. Оновлення операційної системи не впливають на параметри сортування, використовувані SQL Server.)


Важливим доповненням до параметрів сортування стали параметри сортування для східноазіатських мов з підтримкою додаткових символів. Була також додана підтримка порівняння рядків додаткових символів на основі кодової позиції. Для забезпечення можливості істинного порівняння кодових позицій був введений двійковий прапор (BIN2).


При двійкових параметрах сортування і порівняння даних SQL Server виробляються на основі послідовностей бітів для кожного символу. Кожен набір параметрів двійковій сортування в SQL Server відповідає конкретному регіональному мовною стандарту і кодової сторінці ANSI, і кожен забезпечує сортування даних з урахуванням регістра і діакритичних знаків. Параметри двійковій сортування забезпечують саму швидку сортування даних.


Параметр «Двійковий» (_BIN) забезпечує сортування і порівняння даних у таблицях SQL Server на основі послідовностей бітів, визначених для кожного символу. Порядок двійковій сортування враховує регістр і діакритичні знаки. Він також є найшвидшим. Якщо цей параметр не вибрано, SQL Server дотримується правил сортування і порівняння, які використовуються в словниках для відповідної мови або алфавіту.


Параметр «Двійковий-кодова позиція» (_BIN2) для даних в Юникоде забезпечує сортування і порівняння даних у таблицях SQL Server на основі кодових позицій. Для даних в інших кодуваннях параметр «Двійковий-кодова позиція »буде використовувати порівняння, тотожні двійковим сортувань. Перевага використання порядку сортування «Двійковий-кодова позиція» полягає в тому, що в додатках, які порівнюють відсортовані дані SQL Server, не потрібна повторна сортування даних. В результаті порядок сортування «Двійковий-кодова позиція» спрощує розробку додатків і може підвищувати продуктивність.


В Додатку E наведено список параметрів сортування, оновлених у SQL Server 2005. За винятком випадку, коли потрібно забезпечити зворотну сумісність з SQL Server 2000 або більш ранніми версіями, краще користуватися оновленими параметрами.


Параметри сортування в SQL Server 2005 можуть бути наступних типів: параметри сортування Windows і параметри сортування SQL Server.


Параметри сортування Windows


Параметри сортування Windows визначають правила зберігання символьних даних на основі відповідного регіонального мовного стандарту Windows. (Існує більше регіональних стандартів Windows, ніж параметрів сортування Windows для SQL Server.) Правила базових параметрів сортування Windows визначають, який алфавіт або мова використовується, коли застосовується словникова сортування, а також яка кодова сторінка використовується для зберігання символьних даних в кодуваннях, відмінних від Юнікоду. В СУБД SQL Server параметри сортування Windows доповнюються рядом суфіксів, щоб додатково визначити правила сортування та порівняння з урахуванням чутливості до регістрів, діакритичних знаків, типу кани і ширині. Повна назва набору параметрів сортування Windows складається з позначення параметрів сортування і цих стилів порівняння.


Параметри сортування Windows реалізують порівняння і сортування даних у кодуваннях, відмінних від Юнікоду, на основі того ж алгоритму, що і для даних у форматі Юнікод. Це забезпечує узгодженість для різних типів даних, представлених в екземплярі SQL Server, а також дає розробникам можливість сортувати в своїх програмах рядки за допомогою тих же правил, що використовуються SQL Server – тобто викликаючи функцію CompareStringW інтерфейсу Microsoft Win32 API.


Параметри двійковій сортування


Параметри двійковій сортування сортують дані на основі послідовності кодованих значень, що визначаються регіональним мовним стандартом і типом даних. Набір параметрів двійковій сортування в SQL Server визначає, який мовний стандарт і яку кодову сторінку слід використовувати, і примусово застосовує двійковий порядок сортування. Параметри двійковій сортування корисні, коли необхідно домогтися підвищеної продуктивності додатка, оскільки такі режими порівняно просто реалізуються. Для типів даних, які не використовують Юникод, порівняння даних засноване на кодових позиціях, визначених в кодовій сторінці ANSI. Для типів даних, що використовують Юникод, порівняння даних засноване на кодових позиціях Юнікоду. Для параметрів двійковій сортування типів даних, що використовують Юникод, регіональні мовні стандарти при сортуваннях даних не враховуються. Наприклад, режими Latin_1_General_BIN і Japanese_BIN2 при застосуванні до даних формату Юникод дають ідентичні результати сортування. Це відбувається тому, що параметри сортування визначають порівняння даних у форматі Юнікод Юнікод, а дані іншого формату – як виконавчі.


У SQL Server 2000 параметри двійковій сортування для даних у форматі Юнікод приводили до неповного попарному порівнянні кодових позицій. Перший символ порівнювався як значення типу WCHAR, а за цим слід було побайтово порівняння. Для збереження зворотної сумісності існуюча семантика параметрів двійковій сортування змінена не буде.


Параметри двійковій сортування в SQL Server 2005 включають як параметри сортування BIN попередньої версії, так і новий набір параметрів сортування для чистого порівняння кодових позицій. Споживачі можуть віддати перевагу перехід на нові параметри двійковій сортування, щоб скористатися можливістю істинного порівняння кодових позицій. При розробці нових програм повинні використовуватися нові параметри двійковій сортування. Новий суфікс BIN2 позначає імена параметрів сортування, реалізують нову семантику параметрів сортування на основі кодових позицій. Крім того, доданий новий прапор порівняння, відповідний суффиксу BIN2 для нової двійковій сортування.


СУБД SQL Server автоматично пропонує параметри сортування за замовчуванням на основі мови системи. Налаштування параметрів сортування Windows за замовчуванням слід змінювати тільки якщо установка SQL Server повинна відповідати налаштувань параметрів сортування, використовуваним іншим екземпляром SQL Server, або якщо параметри сортування повинні відповідати системному мови іншого комп’ютера.


При необхідності обробляти додаткові символи змініть набір параметрів сортування за замовчуванням на один з новіших, що підтримують операції упорядкування та порівняння для додаткових символів. Порівняння проводиться тільки на підставі кодових позицій, а не будь-яких інших лінгвістично значущих характеристик. Ці операції підтримують тільки параметри сортування версій 90, позначені додаванням суфікса 90 до їх імен. Так, замість параметрів сортування Japanese слід використовувати параметри Japanese_90. Якщо ви не користуєтеся параметрами сортування, враховують додаткові символи, будьте уважні при використанні цих символів в таких операціях, як ORDER BY, GROUP BY і DISTINCT, особливо якщо в однієї операції використовуються і звичайні символи, і додаткові.


Параметри сортування SQL Server


Параметри сортування SQL Server забезпечують сумісність на рівні порядку сортування з попередніми версіями SQL Server. Параметри сортування SQL Server засновані на застарілих порядках сортування SQL Server для даних у форматі, відмінному від Юнікоду (наприклад, для типів даних char і varchar), в тому вигляді, в якому ці порядки визначає СУБД SQL Server. Правила словникової сортування для даних у форматі, відмінному від Юнікоду, несумісні ні з якими процедурами сортування, наданими операційними системами Windows. Проте сортування даних в форматі Юнікод сумісна з однією з версій правил сортування Windows. Оскільки в параметрах сортування SQL Server використовуються різні правила порівняння для даних у форматі Юнікод і інших даних, можна виявити, що порівняння одних і тих же даних дають різні результати. Вони залежать від базового типу даних.


При оновленні примірника SQL Server з метою забезпечення сумісності з існуючими екземплярами SQL Server можна вказати параметри сортування SQL Server. Оскільки для екземпляра SQL Server параметри сортування за замовчуванням вибираються під час установки, важливо ретельно визначити налаштування параметрів сортування в наступних випадках:



Якщо в базі даних знаходяться як стовпці в кодуванні Юнікод, так і стовпці в інших кодуваннях, слід в першу чергу користуватися параметрами сортування Windows. Параметри сортування Windows застосовують правила сортування на основі Юнікоду до даних як в кодуванні Юнікод, так і в інших кодуваннях. Це означає, що для виконання операцій порівняння СУБД SQL Server виробляє внутрішнє перетворення в Юникод даних, кодування яких відмінна від Юнікоду. Це дозволяє забезпечити узгодженість порівняння для різних типів даних, представлених в екземплярі SQL Server, а також дає розробникам можливість сортувати рядки в своїх програмах за допомогою тих же правил, які використовуються і в SQL Server.


З іншого боку, параметри сортування SQL застосовують до даних типів, що не використовують Юникод, правила сортування, не підтримують Юнікод, а до даних формату Юнікод (за допомогою відповідного підтримуючого Юникод набору параметрів сортування Windows) – правила, що підтримують Юнікод. Така відмінність може привести до неузгодженим результатами при порівняннях одних і тих же символів. Тому при обробці в базі даних поєднання стовпців у форматі Юнікод і інших форматах всі ці стовпчики повинні бути визначені за допомогою параметрів сортування Windows, щоб і до даних Юнікоду, і до інших даними застосовувалися одні правила сортування.


Зворотна сумісність параметрів сортування


В СУБД SQL Server 2000 параметри двійковій сортування BIN для даних у форматі Юнікод задавали виконання неповного попарного порівняння елементів коду. При таких параметрах двійковій сортування перший символ порівнювався як значення типу WCHAR, а за цим слід було побайтово порівняння. Це могло призводити до того, що сортування символьних даних в форматі Юнікод відбувалася непередбачуваним чином.


Для забезпечення зворотної сумісності існуюча семантика параметрів двійковій сортування змінена не буде. Однак нові параметри сортування могли стати функциональнее старих. У додатку перераховані параметри сортування, збережені заради зворотної сумісності з версіями SQL Server 2000 і SQL Server 7.0.


Отримати відомості про параметри сортування в базі даних можна за допомогою наступних системних уявлень:





















Представлення каталогу


Опис

sys.databases Повертає відомості про параметри сортування бази даних.
sys.columns Повертає відомості про параметри сортування стовпця в таблиці або поданні.
COLLATIONPROPERTY Повертає відомості про параметри сортування в SQL Server 2005.

Ви можете передати значення CodePage

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*