MySQL - работа с языковыми версиями.

[Royal Flash]

MySQL - работа с языковыми версиями.

На мой взгляд есть 2 способа хранения языковых версий приложения в базе:

1. Таблица: id, body_ru, body_en, ..., т.е. хранение разных языковых версий в разных столбцах.

2. Таблица id, lang_id, body, все языковые версии хранятся в одном столбце, определение какая запись принадлежит какому языку идет по столбцу lang_id.

Multilanguage используется для вывода меню сайта, пользовательские ошибки и т.д. - тоесть система управления сайтом.

Какой из способов лучше и чем? Точнее, возможно, для разных задач имеет смысл использовать разные решения? Просьба поделится здесь вашим опытом в создании многоязыковых приложений в MySQL.

 

[Кром]

Собственно об этом написано уже сотни раз. Делают и так и так.
Первый вариант используют тогда, когда хотят по-быстрому решить проблему одного id для разных языковых версий одного текста.
В остальных случаях используют разновидности второго варианта.

 

[Royal Flash]

Кром
Спасибо за ответ. А можно подробнее о "разновидностях 2-го варианта"?

 

[Кром]

Например, выносишь id и lang_id в отдельную таблицу. А данные хранишь в отдельной таблицы. Или разносишь данные по разным таблицам. Варианты можно придумывать самому в зависимости от ситуации, удобства и быстродействия.

 

[Royal Flash]

Кром
Вы имеете ввиду добавить еще уникальный индекс для каждой строки, и отдельно, в другой таблице хранить текстовые записи с уникальным id для повышения производительности? В моем случае не будет очень много этих самых записей для одного языка, т.е. 100000 - это самый максимум, поэтому, я думаю, не стоит разностить наполнение с логикой по разным таблицам.

 

[Кром]

>в другой таблице хранить текстовые записи с уникальным id для повышения производительности?

Это не для повышения производительности. А для увеличения гибкости системы.

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

 

[Royal Flash]

Кром
Не совсем понял, в чем гибкость... Например, если все находится в одной таблице: id, lang_id и text - то поиск (FULLTEXT) можно разграничить по языковым версиям намного удобнее. В варианте с разбитием на 2 таблицы в запрсе нужно уже будет использовать на 1 таблицу больше.

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

 

[Кром]

Гибкость в том, что ты разделяешь внешние (относительно самого сайта) ключи от внутренних. Т.е. имея таблицу с "внешними" ключами, ты можешь подключать к ней другие таблицы с данными в самых разным вариантах, перенося данных из талицы в таблицу, меняя внутренние id , название таблиц, структуру и т.д. В маленьких проектах это, конечно, покажется не важным, но когда проект большой, пренебрегать старыми id меняя структуры базы, уже не хочется.
FULLTEXT в данном случае просто решение. А ведь индексация может быть как внешняя так внутренняя без всякого FULLTEXT.

>А по поводу производительности, так в умной книге было написано, что индексы быстрее работают там, где нет столбцов с текстом...

Сам по себе столбец без текста никому не нужен, а значит будет еще запрос к столбцу с текстом.