Ако имате нещо близко до избор, използвайте набор от символи Unicode за цялата база данни. Животът като цяло е просто ослепително по-лесен по този начин.
- Има много помощни програми и библиотеки на трети страни, които просто не поддържат колони NCHAR/NVARCHAR2 или които не правят работата с колони NCHAR/NVARCHAR2 приятна. Изключително досадно е, например, когато вашият лъскав нов инструмент за отчитане не може да отчита данните ви NVARCHAR2.
- За персонализирани приложения, работата с колони NCHAR/NVARCHAR2 изисква прескачане през някои обръчи, които работата с CHAR/VARCHAR2 Unicode кодирани колони не прави. В JDBC код, например, вие постоянно ще извиквате метода Statement.setFormOfUse. Други езици и рамки ще имат други проблеми; някои ще бъдат относително добре документирани, а други ще бъдат относително неясни.
- Много вградени пакети ще приемат (или връщат) само VARCHAR2, а не NVARCHAR2. Все още ще можете да ги извикате поради имплицитно преобразуване, но може да се сблъскате с проблеми с преобразуването на набор от знаци.
- Като цяло, възможността да се избегнат проблеми с преобразуването на набор от знаци в базата данни и прехвърлянето на тези проблеми към периферията, където базата данни всъщност изпраща или получава данни от клиент, прави работата по разработването на приложение много по-лесна. Достатъчно е работата, за да се отстранят проблеми с преобразуването на набор от знаци, които са резултат от мрежовото предаване - да се установи, че някои данни са се повредили, когато една съхранена процедура е конкатенирала данни от VARCHAR2 и NVARCHAR2 и е съхранила резултата в VARCHAR2, преди да бъде изпратена по мрежата, може бъде мъчително.
Oracle разработи типовете данни NCHAR/NVARCHAR2 за случаи, когато се опитвате да поддържате наследени приложения, които не поддържат Unicode в същата база данни като нови приложения, които използват Unicode и за случаи, когато е полезно да съхранявате някои Unicode данни с различен кодиране (т.е. имате голямо количество японски данни, които бихте предпочели да съхранявате с помощта на UTF-16 кодиране в NVARCHAR2 вместо UTF-8 кодиране). Ако не сте в една от тези две ситуации и не звучи като че сте, бих избегнал NCHAR/NVARCHAR2 на всяка цена.
Отговаряне на вашите последващи действия
Нашето приложение обикновено е самостоятелно в базата данни на Oracle и се грижи за самите данни. Друг софтуер, който се свързва с базата данни, е ограничен до Toad, Tora или SQL разработчик.
Какво имаш предвид "се грижи за самите данни"? Надявам се, че не казвате, че сте конфигурирали приложението си да заобикаля рутините за преобразуване на набор от знаци на Oracle и че сами извършвате цялото преобразуване на набор от знаци.
Предполагам също, че използвате някакъв API/библиотека за достъп до базата данни, дори ако това е OCI. Разгледахте ли какви промени ще трябва да направите в приложението си, за да поддържате NCHAR/NVARCHAR2 и дали API, който използвате, поддържа NCHAR/NVARCHAR2? Фактът, че получавате Unicode данни в C++ всъщност не означава, че няма да е необходимо да правите (потенциално значими) промени, за да поддържате колони NCHAR/NVARCHAR2.
Ние също така използваме SQL*Loader и SQL*Plus за комуникация с базата данни за основни изрази или за надграждане между версии на продукта. Не сме чували за конкретен проблем с всички тези софтуери относно NVARCHAR2.
Всички тези приложения работят с NCHAR/NVARCHAR2. NCHAR/ NVARCHAR2 въвежда някои допълнителни сложности в скриптовете, особено ако се опитвате да кодирате низови константи, които не са представителни в набора от знаци на базата данни. Със сигурност обаче можете да заобиколите проблемите.
Също така не сме наясно, че администраторите на бази данни сред нашите клиенти биха искали да използват други инструменти в базата данни, които не могат да поддържат данни на NVARCHAR2 и не сме загрижени наистина дали техните инструменти могат да нарушат, в края на краищата те са квалифицирани в работата си и може да намерят други инструменти, ако е необходимо.
Въпреки че съм сигурен, че клиентите ви могат да намерят алтернативни начини за работа с вашите данни, ако приложението ви не работи добре с техния инструмент за корпоративно отчитане или с техния корпоративен ETL инструмент или с каквито и настолни инструменти да имат опит, много вероятно е че клиентът ще обвинява вашето приложение, а не техните инструменти. Вероятно няма да бъде запушалка, но също така няма полза да причинявате ненужна скръб на клиентите. Това може да не ги подтикне да използват продукта на конкурент, но няма да ги накара да прегърнат вашия продукт.
Можем ли също да очакваме срив в производителността, ако нашето приложение (което е компилирано под Visual C++), което използва wchar_t за съхраняване на UTF-16, трябва да извършва преобразувания на кодиране на всички обработени данни?
Не съм сигурен за какви "преобразувания" говориш. Това може да се върне към първоначалния ми въпрос за това дали заявявате, че заобикаляте NLS слоя на Oracle, за да извършите сами преобразуване на набор от знаци.
Изводът ми обаче е, че не виждам никакви предимства от използването на NCHAR/NVARCHAR2 предвид това, което описвате. Има много потенциални недостатъци при използването им. Дори ако можете да елиминирате 99% от недостатъците като неподходящи за вашите конкретни нужди, вие все още сте изправени пред ситуация, в която в най-добрия случай това е измиване между двата подхода. Като се има предвид това, предпочитам да използвам подхода, който максимизира гъвкавостта занапред, а това е преобразуване на цялата база данни в Unicode (вероятно AL32UTF8) и просто използване на това.
