Підтримка мов в СУБД 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. Відсутність цих шрифтів не накладає істотних обмежень на розуміння документа.


Підтримка Unicode в 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 бітів дозволяє представити 65 536 унікальних символів. Проте навіть цього числа недостатньо, щоб охопити всі символи людських мов. У кодуванні UTF-16 певні кодові позиції використовують інші позиції, наступні безпосередньо за першими двома байтами, щоб визначити символи в діапазоні сурогатів.


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


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


У кодуванні UTF-16 для представлення символів, що не входять в основний набір символів (BMP) використовується пара кодових позицій, звана сурогатної парою. Область символів-сурогатів – діапазон Юнікоду від U + D800 до U + DFFF, що включає 1 024 молодших значень сурогатів та 1 024 старших. Старший сурогат (в діапазоні від 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 вони відображаються правильно.



Рис. 1.Використання функції CONVERT з даними у форматі дати / часу


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

Рис. 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>

*

*