многоязыковая поддержка
 

здрям.
для тур-оператора делаю сайт, где должен быть довольно массивный каталог мест размещений. Проблема в том, что вся информация о местах размещений должна быть продублирована на нескольких языках.
Сделать сам интерфейс многоязыковым несложно. я сделал так. для каждой *.php странички есть несколько inc-файлов, каждый из которых содержит переменные вида
$lang['этот идентификатор']='заменяем на этот текст';
и в зависимости от выбранного языка интерфейса подключется нужный инклюд.
с каталогом мест размещений много сложнее. та много инфы, забиваемой вручную, неповторимой. Хочу сделать так.
Будет таблица langtypes(langID,langName) - список всех языков.
Будет таблица lang(textID,langID,val) - каждая строчка текста будет иметь свой textID. Для каждого textID может быть несколько val, каждый val со своим langID. Т.е. данные будут вида:

Таблица langtypes
(langID,langName)
1.........russian
2.........english

Таблица lang
(textID,langID,val)
1......1.............Алушта
1......2.............Alushta
2......1.............Пансионат расположен в горной местности
2......2.............Pansion placed in rocky region

Ну и соответсвенно все поля каталога мест размещений будут ссылаться на textID в таблице lang.

Что спросить хочу. Как вы вообще находите такой метод? Не будет ли проблем? Мест размещения шт
к 500 будет, по каждому штук 10 текстовых полей разной длины.
Как вы бы все организовали?

Можно сделать таблицу
`mystrings` (`id` INT, `str` TEXT);
и таблицу
`str_lang` (`string_id`, `lang_id`)
- это если к нормализации стремиться.

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

Хотя и твой вариант вполне жизнеспособен.

нет, к нормализации я обычно не стремлюсь, если нормализция ведет к лишнему гемморою =)
просто на сайте 200+ человек, все будут постоянно обращаться к данным из этой таблички. меня это слегка пугает =)
вопрос. в моей таблице lang (textID,langID,val), какой тип данных лучше использовать для val?
varchar? просто char? text? размеры таблицы не сильно волнуют, лучше максимально быстрый доступ к искомому индексу.

есть еще вопрос. он вообще по sql'ю, но запостю сюда, чтобы не плодить темы.

итак, есть таблица langtypes (langID,langName) и таблица lang(textID,langID,val).
Есть, например, записи.

Таблица langtypes
(langID,langName)
1.........russian
2.........english
3.........dutch

Таблица lang
(textID,langID,val)
1......1.............Алушта
1......2.............Alushta
2......1.............Пансионат расположен в горной местности
2......2.............Pansion placed in rocky region

Т.е. появился новый язык "dutch", но для него записей в lang нет.
Как составить запрос, который вывел бы все записи по одному textID но для всех langID, так, что если langID не существет, то val=null. Т.е., для
textID например 1 запрос выбрал:

1......1.............Алушта
1......2.............Alushta
1......3.............null

Я здесь не очень шарю. Попробовал
SELECT * FROM ta_langtypes
LEFT JOIN ta_lang ON ta_langtypes.id=ta_lang.langID WHERE textID=1;

основываясь на примере
но не катит. вывел только записи для существующих langID. Я так понимаю, проблема в двойном индексе?

varchar с фиксированной длинной индексируется лучше текста.
Что касается стремления к нормализации - подумай вот о чем: для каждого конкретного пользователя предпочитаемый язык ты определяешь 1 (один) раз за время его сеанса, соответственно дергать таблицу и включать дополнительное условие в КАЖДЫЙ запрос - накладно, не находишь ?

Лично я завел бы для каждого языка отдельную таблицу, это позволит разделить данные друг от друга (не мешать все языки в одной табилце) и размазать данные по таблицам (так как любой СУБД проще работать с небольшими таблицами, а в Вашем случае данных будет не мало).

2Skubent:
читал доку, написано, что текст хранит в таблице первые 256 символов + инфу по длине текста, а остальной блок текста в скрытой табличке.

это мне удобно, потому что 1) куски текста меньше 256 символов хранятся как варчары и скорость доступа, я думаю будет на доли ниже 2) я не парюсь с более длинными кусками текста, а они есть

ну в общем со способом хранения я более-менее определился. уже написано за ночь предыдущую много текста довольно, поэтому менять не буду.в конце концов, если или когда появятся тормоза, можно будет стянуть дополнительную деньгу с заказчика за "модернизацию и отптимизацию" ;-)

Спасибо большое за помощь в этом вопросе.

я там чуть выше описал проблему с запросом. я ее решил правда запросом UNION, но на хостере 3.23 мускуль, он их не потдерживает.
пришлось вручную таблицы клеить в пхп. но я мож дурак, и запрос совсем другой должен быть =/

Нет, надо пинать хостера на смену мускля, уже 5-ка имеет место быть в стэйблах :)

И все таки подумай, надо ли тебе все языки в одну таблицу пихать.

хостер гад пинать себя не дает, аргументируя тем, что у него на сервере докуя виртуальных хостов и баз.
еще у него, гада, пхп 4ка, блин.
а хмл парсер, который я использовал, появился только в пятерке. $%#.
вот думал завернуть функции парсера в свой класс, поленился =(
теперь с этим кодом... сексом заниматься =(

Chas, виртуальные сервера сейчас вроде не очень дорого предлагают :)