[Comm] Re: Еще о локали utf-8 и файле Compose
Aleksey Avdeev
=?iso-8859-1?q?solo_=CE=C1_solin=2Espb=2Eru?=
Ср Янв 28 18:45:22 MSK 2004
Alexej Kryukov пишет:
> On Wednesday 28 January 2004 16:49, iceb на svitonline.com wrote:
>
>>В Срд, 28 Янв 2004, [koi8-r] Денис Смирнов написал(а):
>>
>>ДС> Любая вменяемая СУБД поддерживает перекодировку. Я из
>>ДС> постгреса уже давно
>>ДС> получаю данные в той кодировке, в которой мне сию секунду
>>ДС> удобнее. Внутри
>>ДС> хранится так же в той кодровке, в которой _мне_ это
>>ДС> покажется разумным.
>>
>>Уточняю за вас: перекодировка - из не-юникодовой локали в
>>произвольную локаль. Это - нормально и хорошо. Но речь же не об этом
>>шла. А о том, что держать (и обрабатывать) текстовые данные в базе в
>>юникоде - идиотизм.
>
>
> А вот этого я уже не понимаю. IMHO, везде, где требуется работа
> с разными кодировками, приложение должно держать данные в
> Юникоде, а преобразование осуществлять на входе и выходе.
> Собственно, большинство программ теперь так и делает.
Разница в объёме данных, а следовательно в накладных расходах на:
1. хранение (диски не резиновые)
2. резервное копирование (ленты не резиновые + время +
_физический_ объём)
3. скорость обработки (в том числе - полнотекстовый поиск)
4. поддержка индексов (объёмы + скорость поиска)
5. ...
Собственно уменьшение размера поля на 1 _бит_ - уже большой
"+" для крупной БД! А Вы предлагаете 2х кратное _увеличение_
объёма для кириллической информации...
--
С уважением. Алексей.
Подробная информация о списке рассылки community