Установка дополнительного языка в БД.

synthetic
Дата: 07.12.2012 13:05:26
Здравствуйте. Прошу помочь решить следующую проблему. Имеется база данных (Oracle 10g) с поддержкой латиницы и кириллицы. Возникла необходимость добавить еще один язык - каазахский (если я правильно понимаю, кодировка CP1251-k). Подскажите пожалуйста, как можно это сделать?
tru55
Дата: 07.12.2012 13:30:45
вариант1
Хранить данные с новой кодировкой в NVARCHAR2 (поскольку там поддерживается unicode)
вариант 2
Создать новую БД с кодировкой, которая поддерживает все 3 языка и перенести туда данные старой БД через exp/imp
synthetic
Дата: 07.12.2012 14:52:58
tru55, то есть вы предлагаете во всей базе данных у полей с типом VARCHAR2 поменять тип на на NVARCHAR2?
synthetic
Дата: 07.12.2012 14:53:56
Вариант с созданием новой БД и переносом туда данных отпадает, т.к. база необъятных размеров.
orawish
Дата: 07.12.2012 15:02:08
synthetic
Вариант с созданием новой БД и переносом туда данных отпадает, т.к. база необъятных размеров.

ой не того (куста в ночи ) вы пугаетесь, чего пугаться следовало бы.
имхо - это самый дешевый путь
synthetic
Дата: 07.12.2012 15:26:48
orawish, в БД более 3000 таблиц, абоентская база - 20000 человек. С другой стороны, необходимые текстовые данные, которые должны так же содержать символы казахского языка, подтягиваются из определенного набора таблиц, т.н. словари.
Так что еще не известно, какой вариант предпочтительнее.
orawish
Дата: 07.12.2012 15:48:58
synthetic
orawish, в БД более 3000 таблиц, абоентская база - 20000 человек. С другой стороны, необходимые текстовые данные, которые должны так же содержать символы казахского языка, подтягиваются из определенного набора таблиц, т.н. словари.
Так что еще не известно, какой вариант предпочтительнее.

что с чем вы сравниваете?
я сравнивал:
1) изменение декларации всех колонок всех таблиц varchar2/char на nvarchar2 (nchar ) + соответствующий переколбас всего серверного и клиентского api
2) и перенос базы на сервер с многобайтовой кодировкой(+сигнатурой) ну и последующий анализ возможных проблем
с данными (на лимиты, в частности) и соответствующую доводку структур базы, данных и приложений
orawish
Дата: 07.12.2012 15:54:41
synthetic,

кстати, про большую базу.
вот у меня под руками есть (имхо) - не очень большая
SQL> select count(*) from user_segments;

  COUNT(*)
----------
    354034 

;)
synthetic
Дата: 07.12.2012 16:32:25
orawish, хм, ну я даже не знаю :) пожалуй, второй вариант и правда звучит привлекательнее. Спасибо.
d.nemolchev
Дата: 09.12.2012 19:57:19
synthetic,

Ваша проблема давно решена и нормально работает для кодировки СТ РК 1048-2002.
Это делается расширением characterset-а CL8MSWIN1251, лингвистической сортировки RUSSIAN и подменой (после определенной доработки напильником скомпилированных nlb-шек) соответствующих штатных nlb-файлов lx200ab.nlb и lx30023.nlb в директории $ORACLE_HOME/nls/data/.
В итоге имеем БД в кодировке CL8MSWIN1251, которая "понимает" специфические 9 букв казахского алфавита, правильно их сортирует, upper-ит, lower-ит, initcap_ит...
Путь, конечно, как бы не совсем правильный, но ввиду большого объема БД, ИМХО, это лучше, чем переводить базу в юникод, который сразу удвоит объем, занимаемый текстовыми данными...
7-й год - полет нормальный