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

[Chas]

здрям.
для тур-оператора делаю сайт, где должен быть довольно массивный каталог мест размещений. Проблема в том, что вся информация о местах размещений должна быть продублирована на нескольких языках.
Сделать сам интерфейс многоязыковым несложно. я сделал так. для каждой *.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 текстовых полей разной длины.
Как вы бы все организовали?

[Skubent]

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

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

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

[Chas]

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

[Chas]

есть еще вопрос. он вообще по 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;

основываясь на примере

SELECT table1.* FROM table1
LEFT JOIN table2 ON table1.id=table2.id
WHERE table2.id IS NULL;

This example finds all rows in table1 with an id value that is not present in table2 (that is, all rows in table1 with no corresponding row in table2).

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

[Skubent]

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

[rtm]

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

[Chas]

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

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

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

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

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

[Skubent]

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

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

[Chas]

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

[Skubent]

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