Проблемы с длинной идентификаторов на кирилице в Юникоде

vadiminfo
Дата: 06.03.2007 16:06:05
Привет, всем!
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod
ОС Винды
NLS_CHARACTERSET = AL32UTF8

Попытка использовать для идентификатров с русскими символами
select 1 "Ф01234567890123456789012345678" from dual

Приводит к ORA-00972.
Типа два байта на симовол.

Однако, для пользовательских табл, в частности после установки параметра инициализации
nls_length_semantics в значение CHAR проблема решается вопрос, например, для значение полей
(ошибка ORA-12899 - значение слишком длинное).

Но для идентификатров не помогает.
Вопрос: можно ли как-то добиться, чтобы с идентификаторами тоже удалось снять вопрос.
Причина в переносе БД в которой полно идентификаторов на кириллице. Желательно, чтобы ее не править.
orawish
Дата: 06.03.2007 16:30:50
vadiminfo
Привет, всем!
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod
ОС Винды
NLS_CHARACTERSET = AL32UTF8

Попытка использовать для идентификатров с русскими символами
select 1 "Ф01234567890123456789012345678" from dual

Приводит к ORA-00972.
Типа два байта на симовол.

Однако, для пользовательских табл, в частности после установки параметра инициализации
nls_length_semantics в значение CHAR проблема решается вопрос, например, для значение полей
(ошибка ORA-12899 - значение слишком длинное).

Но для идентификатров не помогает.
Вопрос: можно ли как-то добиться, чтобы с идентификаторами тоже удалось снять вопрос.
Причина в переносе БД в которой полно идентификаторов на кириллице. Желательно, чтобы ее не править.
Пока, нет
AI
Дата: 06.03.2007 16:30:51
vadiminfo
Привет, всем!
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod
ОС Винды
NLS_CHARACTERSET = AL32UTF8

Попытка использовать для идентификатров с русскими символами
select 1 "Ф01234567890123456789012345678" from dual

Приводит к ORA-00972.
Типа два байта на симовол.

Однако, для пользовательских табл, в частности после установки параметра инициализации
nls_length_semantics в значение CHAR проблема решается вопрос, например, для значение полей
(ошибка ORA-12899 - значение слишком длинное).

Но для идентификатров не помогает.
Вопрос: можно ли как-то добиться, чтобы с идентификаторами тоже удалось снять вопрос.
Причина в переносе БД в которой полно идентификаторов на кириллице. Желательно, чтобы ее не править.


Для идентификаторов длина 30 байт. Это не обойдешь...

Кстати, varchar2(4000 char) тоже попытка замести мусор под ковер, поскольку максимальная длина данных 4000 байт, но не символов.

csscan поможет найти проблемные имена и данные при переносе в юникод.
orawish
Дата: 06.03.2007 16:36:43
Еще полкопейки - имхо, если жили на однобайтовой кодировке, то вдруг AL32UTF8 == от лукавого.
Особенно мощная причина (типа) - ну она же сама лезет, по умолчанию
vadiminfo
Дата: 06.03.2007 19:30:26
AI
Для идентификаторов длина 30 байт. Это не обойдешь...


Дело не столько в 30 байт, сколько в том, что на кирилице в Юникоде получается всего 15 симоволов, тогда как на латинице 30.
Для длинны значений они решили проблему. Т.е. можно создать таблу, где и кирилица будет 30 в Юникоде.
Получается как-то по стилю не замкнуто. Идентификаторам вроде тоже на логическом уровне мешает то, что в таблах словаря отведено по 30. Конечно, может еще что, более глубокое.

Хотя и само ограничение 30 символов тоже иногда мешает - усложняет удаленные запросы из Оракла, например, к Аксцессу (В нем нет таких ограничений и иногда встречаются длянные поля.)


AI
Еще полкопейки - имхо, если жили на однобайтовой кодировке, то вдруг AL32UTF8 == от лукавого.

Не жили, а заказчики были когда-то только отчественные. Впрочем, дело в концепции. Можно или нельзя.
orawish
Дата: 06.03.2007 19:44:44
vadiminfo
..Не жили, а заказчики были когда-то только отчественные. Впрочем, дело в концепции. Можно или нельзя.

Ну, тогда пора менять концепцию.. Повод есть. А для отчественных можно синонимов настрогать. Хотя - и это, имхо, как чтоб на спичках экономить, запалить ассигнацию и от неё прикуривать..
AI
Дата: 06.03.2007 20:07:52
vadiminfo
AI
Для идентификаторов длина 30 байт. Это не обойдешь...


Дело не столько в 30 байт, сколько в том, что на кирилице в Юникоде получается всего 15 симоволов, тогда как на латинице 30.
Для длинны значений они решили проблему. Т.е. можно создать таблу, где и кирилица будет 30 в Юникоде.
Получается как-то по стилю не замкнуто. Идентификаторам вроде тоже на логическом уровне мешает то, что в таблах словаря отведено по 30. Конечно, может еще что, более глубокое.

...


Дело именно в байтах. Под имена объектов выделено до 30 байт и ни байтом больше (я не беру в расчет синонимы и линки). В utf8 и его разновидностях вроде al32utf8 символы латиницы занимают 1 байт, кириллицы и некоторых других языков - два байта, а китайские иероглифы 3-4 байта в зависимости от страницы. И с этим надо смириться.

Насколько я понимаю ситуацию, так можно без лишних затрат ввести юникод в программу, которая была "однобайтной" (6 и ранние 7) без переписывания большого количества отлаженного и рабочего кода.

По поводу "решили проблему" в данных я уже написал. Можно упереться в другие ограничения, но чуть позже.

Еще раз рекомендую воспользоваться csscan, чтобы найти проблемные данные.

vadiminfo

AI
Еще полкопейки - имхо, если жили на однобайтовой кодировке, то вдруг AL32UTF8 == от лукавого.



Это не я писал.

А "концептологам" надо было знать ограничения оракла на длины имен до начала работы. Тем более, что юникод в оракле появился с 7.3 (или с 7.2 - не помню), а это было году в 1995. То есть, как минимум, 11-12 лет назад.
vadiminfo
Дата: 06.03.2007 20:51:54
AI

Дело именно в байтах.

Наверное, я не удачно выразил мысль. С данными то проблем нет. Оракл позволяет для кирилических данных 30 символов (60 байт) - тип varchar2 (30 CHAR). Ожидалось что и для идетификаторов было логично реализовать подобное. Потому была надежа.



AI
Это не я писал.

Извиняюсь. Опечатка.


AI

А "концептологам" надо было знать ограничения оракла на длины имен до начала работы. Тем более, что юникод в оракле появился с 7.3 (или с 7.2 - не помню), а это было году в 1995. То есть, как минимум, 11-12 лет назад.

Не спорю, что надо. Под концетолагами, однако, понимал парней из фирмы Оракл. Все еще считаю, что 15 символов это слишком. А если 3 байтные символы - 10. И они видимо так отчасти считают, сделав для данных таки 30. Почему не пошли дальше и для индентификаторов не сделали тоже?
Вот о какой концепции я. А не концепции проектирования нашми пранями БД. Они не лидирующая мировая фирма, к ним и спрос меньше. Тем более на стадии концептуального проектирования думать о байтах не стильно. (Шуткэ, но с долей правды).
softwarer
Дата: 06.03.2007 21:43:10
vadiminfo
Почему не пошли дальше и для индентификаторов не сделали тоже?

Потому что "идентификаторы" обрабатываются иначе, нежели "данные". Ограничение в 30 байт, конечно, анахронизм и крайне неудобно, но его волевая отмена приведет к сотням, если не тысячам, проблем в ядре и основных утилитах (которые написаны на сях, в которых никакого [30 char] не предусмотрено).
vadiminfo
Дата: 06.03.2007 23:09:33
Спасибо всем за ответы. Придется править идетификаторы.