Dmitry67 wrote:1 Я не согласен Действительно, хранить unicode в базе когда это реально не нужно - расточительство
Не совсем.
Никогда не знаешь что когда понадобится Например Oracle при charset AL32UTF8 (Unicode 3.2) на каждый символ отводит столько байт сколько надо - если с клиента приходит ASCII символ под него будет отведен ровно 1 байт, если приходит к примеру ß - два байта - китайский иероглиф - три байта, спец символ - 4 байта. Microsoft работает в кодировке (Unicode) USC-2 где под каждый символ отводится или два или четыре байта.
Location: SPB --> Gloucester, MA, US --> SPB --> Paris
Postby Dmitry67 »
Причины по которым базу на MS SQL не нужно переводить на unicode 'просто так' сводятся к следующему
1. Падение скорости до двух раз изза увеличеияобъема базы
2. Ограичение row size (за исключением полей типа TEXT) в 9 с небольшим K
3. Ограничение row size индекса (то есть мак суммы длин всех индексируемых полей) в 900 с чем то байт
По поводу второго замечания не понял
Если база в Unicode, то как не unicode клиент покажет текст в общем случае ?
Зарегистрированный нацпредатель, удостоверение N 19719876044787 от 22.09.2014
Я не могу назвать себя специалистом в области UNICODE - всю свою сознательную жизнь провел в SBCS. Но вот ссылочку на эту тему - как обстояли и обстоят дела в DB2 могу предложить:
может быть не самая лучшая, но по крайней мере мне ясно что уже с конца 80-х в DB2 поддерживался DBCS - предтеча и ныне частный случай UNICODE, а в версии 8 все в DB2 на UNICODE переведено - не только пользовательские данные, но и системные данные в том числе.
Приведенная ссылка - только часть первая, второй пока нет. Смотрите следующий номер на:
Dmitry67 wrote:.......... 1 Я не согласен Действительно, хранить unicode в базе когда это реально не нужно - расточительство Во всех остальных случаях должен быть UNICODE Пишущий сейчас неunicode клиента подобен пишущему под Win16
............
Dmitry67, для Вас в ссылке, приведенной мною выше, читайте о двух мифах, связанных c UNICODE.
Dmitry67 wrote:Причины по которым базу на MS SQL не нужно переводить на unicode 'просто так' сводятся к следующему
1. Падение скорости до двух раз изза увеличеияобъема базы 2. Ограичение row size (за исключением полей типа TEXT) в 9 с небольшим K 3. Ограничение row size индекса (то есть мак суммы длин всех индексируемых полей) в 900 с чем то байт
По поводу второго замечания не понял Если база в Unicode, то как не unicode клиент покажет текст в общем случае ?
Вы хотите сказать, Дима, что SQL Server использует UCS-2, который (если я правильно понял) все прогрессивное компьютерное сообщество отвергло?
Location: SPB --> Gloucester, MA, US --> SPB --> Paris
Postby Dmitry67 »
zVlad wrote:
Dmitry67 wrote:Причины по которым базу на MS SQL не нужно переводить на unicode 'просто так' сводятся к следующему
1. Падение скорости до двух раз изза увеличеияобъема базы 2. Ограичение row size (за исключением полей типа TEXT) в 9 с небольшим K 3. Ограничение row size индекса (то есть мак суммы длин всех индексируемых полей) в 900 с чем то байт
По поводу второго замечания не понял Если база в Unicode, то как не unicode клиент покажет текст в общем случае ?
Вы хотите сказать, Дима, что SQL Server использует UCS-2, который (если я правильно понял) все прогрессивное компьютерное сообщество отвергло?
А Вы хотете сказать zVlad, что DB2 Использует EBCDIC, которое все прогрессивное человечество отвергло уже давно ? Это шютка
Я пытался найти как хранится UNICODE на сервере
Явно - нигде не написано
Но везде написано типа max длина varchar 8000, nvarchar 4000
Так что ответ напрашивается
Зарегистрированный нацпредатель, удостоверение N 19719876044787 от 22.09.2014
JustMax wrote:Как там с глобализацией в Юконе будет ? По сравнению с 2000 - ым или с Oracle.
Так как глобализация/локализация касается меня по касательной, то я не в курсе этих отличий Yukon от SQL Server 8.0 за исключением пары вещей: добавлена поддержка для четырёхбайтных китайских MBCS символов (что нужна для какой-то важной сертификации) и XML data type, поддерживающий хранение в UCS-2/UTF-8/UTF-16. Хоть для storage engine это абсолютно всё равно (любые данные SE рассматриваются как массивы байт), хранение NCHAR/NVARCHAR/NTEXT в таблицах в самом быстром для доступа варианте - UCS-2. CHAR/VARCHAR/TEXT MBCS хранится компактно, но, соответственно, строковые функции с такими данными работают медленнее.
JustMax wrote:Как там с глобализацией в Юконе будет ? По сравнению с 2000 - ым или с Oracle.
Так как глобализация/локализация касается меня по касательной, то я не в курсе этих отличий Yukon от SQL Server 8.0 за исключением пары вещей: добавлена поддержка для четырёхбайтных китайских MBCS символов (что нужна для какой-то важной сертификации) ...
4-х байтне китайские символы - это надо понимать GB-18030 support. Нужён для сертификации правительством PRC (People Republik of China) для того, чтобы продукт мог продаваться на территории КНР.
