[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