Как правильно должна быть построена БД для мультиязычного содержания?

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

Сейчас у меня сделано так:



Но скорость выполнения запроса оставляет желать лучшего. При выборе 10 случайных товаров на запрос уходит 2-3 секунды, а в базе 20000 товаров и 3 языка.

Перевод названий должен быть в одной таблице для всех языков или в разных для каждого? 

Вариант - отделить названия товаров от таблицы связей. Полностью.
//Список названий языков. Для выбора в интерфейсе.
languages(idlanguage,string)
INDEX idlanguage
_
// Просто список идентификаторов продукта. Если имеются данные о продукте, не привязанные к языку отображения, могут быть заненсены в эту базу. Но по условию, таких данных нет. 
products(idproduct)
INDEX idproduc(autoinc)
_
// Названия продукта в разных языках
product_names(idproduct,idlanguage,name:string)
INDEX idproduct,idlanguage
_
// список аттрибутов. Если имеются характеристики аттрибутов, не привязанные к языку, могут быть занесены.. нет, не в Красную книгу   ...сюда, в эту базу
attributes(idattribute)
INDEX idattribute
_
// названия аттрибутов на разных языках
attribute_names(idattribute,idlanguage,name:string)
INDEX idattribute,idlanguage
_
// как я понял, значения аттрибутов - текстовые? тут хранится только связка аттрибута продукта с конкретным значением аттрибута
attribute_values(idproduct,idattribute,idvalue)
INDEX idproduct,idattribute
_
// Перевод значения аттрибута на разные языки...
attribute_values_names(idvalue,idlanguage,name)
INDEX idvalue,idlanguage
_____
Возможно, громоздко вышло. На гениальность не претендую 
Какая БД, кстати? Ведь если Вы вдруг надумаете переводы пихать в разные таблицы, в соотвествии с языков, в некоторых СУБД Вас будет ожидать сюрприз в виде невозможности выполнения динамического SQL-запроса(например, в MySQL), и при добавлении нового языка придётся переписывать программу...   

Это сообщение отредактировал(а) skyboy - 22.5.2006, 00:50

У нас локализация сделана на основе одной таблицы лейблов. Упрощенно, поля её таковы:
ID (номер)
Locale (локаль)
Title (название лейбла)
Value (значение)

Т.е. содержимое может быть примерно таким:
ID |  Locale  |            Title          |   Value
===========================
1   | EN_UK  |  WINDOW_TITLE  |  "Title"
2   | EN_US  |  WINDOW_TITLE  |  "Title"
3   | RU_RU  |  WINDOW_TITLE  |  "Заголовок"

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

ну во первых мульти-локэил данные нужно сохранять в базе без потери этого языка... и это уже вопрос к конкретному серверу БД.
может быть сервер поддерживает столбцы UNICODE, а может и нет. Нужно вообщем сразу выяснить как ваш сервер сможет  тексты на иврите, русском и английском хранить в одном столбце одной табилцы. в худшем случае придеться сливать их как binary data...

Мы пошли таким же путем как Lamer George. у нас одна таблица для всех локализированных текстов, с тройным ключом: Locale, ObjectType, ObjectID. Причем ObjectID - альфанумерик и хранит фактически primary key из других таблиц без cохранения оригинального типа этого ключа. хорошо это тем что удобно - одна таблица для локализации чего угодно. плохо это тем что не возможно наложить Foreign key. Т.е. фактически эта таблица денормализует базу... 

Спасибо! Очень хорошее решение.