Меню
Что нового?

Как правильно хранить различные кодировки в одной базе?

Иван 76

Новичок
Как правильно хранить различные кодировки в одной базе?

Добрый день.

Существует промышленный интернет-проект на русском языке.
Сейчас из него делается интернациональное мультиязычное приложение.

Локализация давно уже решена с помощью gettext. Есть вопрос по организации хранения данных.

В силу определенных объективных и субъективных причин (большой объем переделок, мое нежелание и пр., техническая независимость от хостера, большой объем данных в юникоде...), я не очень хочу использовать UTF-8.

А при использовании различных кодировок, я вижу два варианта хранения данных:
1. Все данные в одной таблице, при этом имеется поле lang_id - которое указывает, к какой языковой версии относится запись.
2. Разнести данные по различным таблицам, при этом талицы разных языковых версий будут иметь суффикс типа *_ru, *_de, *_en, *_fr и т.д...., например production_ru, production_de ...

При использовании второго способа, все осуществляется гораздо проще:
1. Для каждой таблицы можно легко задать кодировку и сопоставление (collation)
2. Уменьшается объем и без того больших таблиц (точнее - он не так сильно увеличится с переходом на мультиязычность). Что должно отразится на производительности.

Недостатки:
1. нужно сильно много плодить таблиц, что неудобно
2. Требуется правка огромного количества кода.

Со вторым вариантом, если все хранить в одной таблице, этих недостатков можно избежать. Править скриптов - меньше, соответственно - меньше вероятность ошибки.

Но:
1. Непомерно вырастет объем таблиц. На 150 000 прайс - строк - более 500 000 строк в таблице - это не есть гуд. Хотя, при правильном построении индекса... но все же...
2. Возникает ВОПРОС ПО КОДИРОВКАМ, ответа на который я в форуме НЕ НАШЕЛ.

Как хранить разные кодировки в одной таблице, например iso-8859-1 и cp1251?

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

Тем не менее, хранить такой винигрет - могут возникнуть вопросы в будущем, которые я пока не могу предвидеть.

А посему вопрос к тем, кто имеет подобный опыт:
1. Как бы поступили Вы в данной ситуации?
2. Что Вы по этому поводу думаете?

Заранее спасибо.
 
jonjonson

jonjonson

Охренеть
я не очень хочу использовать UTF-8
Нажмите для раскрытия...
Если решил и знаешь к чему это приведёт, то зачем был остальной текст писать?

Вот ещё вариант. Создай под каждый язык свою БД =)
 

Иван 76

Новичок
Автор оригинала: jonjonson
Если решил и знаешь к чему это приведёт, то зачем был остальной текст писать?

Вот ещё вариант. Создай под каждый язык свою БД =)
Нажмите для раскрытия...
Если честно, я еще ничего не решил. Но больше склоняюсь к хранению в разных таблицах.

Создать под каждый язык свою базу не получится, така как некоторые таблицы содержат уникальную информацию для всех языков. Например, авторизационные данные, идентификаторы регионов, рубрик, разделов и пр..., которые выводятся составными запросами.
 
Mr_Max

Mr_Max

Первый класс. Зимние каникулы ^_^
Команда форума
Храните данные в одной кодировке.
К нужной приводите при выборке из БД.

PHP: 
<?php
/**
 * @param $string
 * @param $from [string] The name of the current character set of $string, in MySQL format (e.g. "utf8", "hebrew").
 * @param $to [string] The name of the character set to which you want to convert $string.
 * @author Erel Segal - Rent a Brain ([url]http://tora.us.fm/rentabrain[/url])
 * @date 2006-12-10
 */
function mysql_iconv($string, $from, $to) {
    // keep current character set values:
    $character_set_database = mysql_result(mysql_query("SELECT @@character_set_client"),0,0);
    $character_set_results = mysql_result(mysql_query("SELECT @@character_set_results"),0,0);

    mysql_query("SET character_set_client=$from");
    mysql_query("SET character_set_results=$to");

    $string_escaped = mysql_real_escape_string($string);
    $converted_string = mysql_result(mysql_query("SELECT '$string_escaped'"),0,0);

    // restore previous character set values:
    mysql_query("SET character_set_client=$character_set_database");
    mysql_query("SET character_set_results=$character_set_results");

    return $converted_string;
}

?>
http://ua2.php.net/manual/ru/ref.iconv.php#71644
 

Иван 76

Новичок
Автор оригинала: Mr_Max
Храните данные в одной кодировке.
К нужной приводите при выборке из БД.
Нажмите для раскрытия...
Честно говоря, не знаю как можно конвертировать cp1251 в iso-8859-1

Эти кодировки не имеют общих символов вообще (кроме латиницы). Они из разных языков.
Я понимаю конвертировать разные кодировки одного языка cp1251 в
koi8-r, или iso8859-5, или x-cp866, или x-mac-cyrillic

Но конвертировать буквы французского алфавита в кирилицу....????

И потом, смена кодировки средствами PHP не решает проблемы collation в БД. Как тогда база будет производить сортировку по алфавиту? Как делать регистронезависимый поиск?

Даже если использовать UTF-8, проблема collation остается, так как сопоставление в UTF-8 для разных языков различное. Это влияет на сортировку. Но, в принципе, это решаемый вопрос, его можно решить, так как collation можно задать в самом запросе.

При UTF-8 все было бы проще. Но мне тогда нужно месяц ковырять скрипты - много правок будет (например strlen(), eregi(), substr()...)
 

Апельсин

Оранжевое создание
а в чем проблема с collation? ставите нужные collation на уровне таблиц или даже столбца и все.
 

Апельсин

Оранжевое создание
ну если все собираетесь хранить вообще в одной таблице, то тогда collation в запросе непосредственно указывать только
но имхо, все лучше делать разбиение на разные таблицы.

-~{}~ 03.07.07 22:52:

кстати если у вас будут хранится англоязычные данные (latin1) и русскоязычные данные то вам подойдет utf8_general_ci.
 
Wicked

Wicked

Новичок
Иван 76
даже если хранить данные в двух кодировках - latin1 (iso-8859-1) и cp1251, то как вы собираетесь:
1) при одновременной выборке и тех, и других, понимать, какие есть какие?
2) как это все отдавать браузеру? например, в какой кодировке делать страницу?
 

Иван 76

Новичок
Автор оригинала: Wicked
Иван 76
даже если хранить данные в двух кодировках - latin1 (iso-8859-1) и cp1251, то как вы собираетесь:
1) при одновременной выборке и тех, и других, понимать, какие есть какие?
2) как это все отдавать браузеру? например, в какой кодировке делать страницу?
Нажмите для раскрытия...
Это отражено в описании темы:
>Все данные в одной таблице, при этом имеется поле lang_id - которое указывает, к какой языковой версии относится запись.

В браузер, в пределах одной страницы, отдаются данные только в одной кодировке только одного языка (языковой версии сайта).
Другая кодировка выводится при смене языковой версии.

-~{}~ 04.07.07 21:04:

Автор оригинала: Апельсин
ну если все собираетесь хранить вообще в одной таблице, то тогда collation в запросе непосредственно указывать только
но имхо, все лучше делать разбиение на разные таблицы.

-~{}~ 03.07.07 22:52:

кстати если у вас будут хранится англоязычные данные (latin1) и русскоязычные данные то вам подойдет utf8_general_ci.
Нажмите для раскрытия...
Спасибо. Полностью согласен и то же склоняюсь к такому решению.
Разные таблицы мне больше нравится, хоть это и создает дополнительные рабочие моменты.

>кстати если у вас будут хранится англоязычные данные (latin1) и русскоязычные данные то вам подойдет utf8_general_ci.
С русским и английским проблем нет, и они прекрасно сочетаются и в CP1251. Вопросы возникают с французским, немецким и пр.

> то вам подойдет utf8_general_ci.
Действительно, это был бы хороший вариант, эта мысль меня то же посещала.
Но тогда объем базы вырастет практически в два раза. Она и так немаленькая.
У меня так же есть сомнение по поводу скорости выборки на UTF-8 (не располагаю фактами но предполагаю), а так же времени на конвертацию, хотя последним можно пренебречь по причине мизерности.
 
tf

tf

крылья рулят
о отображении отображаемых данных на сайте не думал?
админить utf-8, на морде работать с копией в нужной кодировка?
У меня так же есть сомнение по поводу скорости выборки на UTF-8 (не располагаю фактами но предполагаю), а так же времени на конвертацию, хотя последним можно пренебречь по причине мизерности.
Нажмите для раскрытия...
цифры где?
 

Иван 76

Новичок
tf
>о отображении отображаемых данных на сайте не думал?
Не понятен вопрос

>цифры где?
В приводимой вами цитате: (не располагаю фактами но предполагаю)

Логика вещей такова: Быстрее чем CP1251 работать не будет (объем данных вырастает до двух раз). Согласен, время выборки вероятней всего вырастет. Не знаю на сколько. Думаю - не на много. Меня больше интересует как это отразится на обработке 1 000 000 строк.

Проводить эксперименты сечас нет времени. Если Вы заметили периодичность моих ответов - я бываю за компьютером по одному часу на сутки (вечером). Появится время - может попробую поэксперементировать.

Но - скорее всего остановлюсь на разделенных таблицах. С каждым днем все больше убеждаюсь в этом.
 

Иван 76

Новичок
Автор оригинала: tf
меня это мало волнует
Нажмите для раскрытия...
... меня это не задевает... Все равно ничего дельного не сказал...

-~{}~ 05.07.07 21:02:

Ребята. Спасибо всем, особенно Апельсин.
Его ответ утвердил мой выбор в пользу разнесенных таблиц.
Похоже, он сталкивался с аналогичной проблемой на практике.
Тема закрыта.
 
AnToXa

AnToXa

prodigy-одаренный ребенок
Иван 76
гыгы, Апельсин - девушка :) улыбаемся и машем :)
 

.des.

Поставил пиво кому надо ;-)
[offtop]Иван 76, Апельсин - это она.

-~{}~ 06.07.07 00:39:

Ниче я так опоздал :D
 
direqtor

direqtor

Новичок
Делаю сейчас примерно такую же базу с полями lang_id. И объем предполагается в несколько сотен тысяч строк. Но крепко подумав решил и админку и данные создавать в UTF. А вот в сайт можно отдавать перекодировав в нужную кодировку. Да и расширяемость на еще один язык упрощается.
 
Войдите или зарегистрируйтесь для ответа.
Сверху