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

Question

[максим кошкин]

На проекте в данный момент реализован следующий вариант:
+--------------+
| post
+--------------+
| id
| name_ru
| name_en
+--------------+
То есть каждое поле, требующее перевода, тут же, в таблице, хранит значение на других языках.
Встала задача реализовать возможность динамически добавлять языки в админке - от существующего варианта придётся отказаться.
Наиболее удачное решение, на мой взгляд - добавить таблицу для языков (lang), а оригинальную post развалить на две таблицы - post (останётся только атрибуть id) и post_lang для хранения post_id, lang_id и name.

Но возник вопрос - можно ли пойти ещё дальше? Чтобы для каждой таблицы table, поля которой требуют перевода, не создавать соответствующую таблицу table_lang, а завести в базе что-нибудь типа table_attribute, которая будет хранить table_name и attribute_name, по сочетанию которого можно однозначно идентифицировать поле, требующее перевода, а далее для поиска перевода использовать комбинацию table_attribute_id (какое поле какой таблицы переводим) + lang_id (на какой язык) + record_id (для какой конкретно сущности).

То есть структура таблиц развалится ещё больше:
+--------------+
| post
+--------------+
| id
+--------------+

+--------------+
| lang
+--------------+
| id
| name
+--------------+

+------------------+
| table_attribute
+------------------+
| id
| table_name
| attribute_name
+------------------+

И, наконец:

+------------------+
| entity_attribute
+------------------+
| id
| table_attribute_id
| lang_id
| record_id
| value
+------------------+

То, что в приложении ждёт кошмар, я понимаю. Хочется услышать критику именно в сторону такой структуры, можно ли на ней далеко уйти чисто в теории, или же следует остановиться на варианте с таблицей перевода для каждой сущности (post - lang - post_lang)? Таких сущностей на самом деле пока не очень много (10-15 таблиц), и добавить для каждой по таблице перевода недолго - но какой вариант будет больше готов к изменениям и дальнейшему развитию?
Следует ли избавиться от table_attribute и перенести комбинацию table_name - attribute_name в последнюю таблицу entity_attribute. С одной стороны, с отдельной таблицей выглядит почище, с другой стороны - необходимость постоянно строить эту связь, чтобы добраться до перевода.
Может, кто-то решал проблему мультиязычности и нашёл для себя самый лучший подход - буду рад любому совету

Answer 1

[YepBro]

Другие варианты есть.

1) Переводы хранить в поле типа json. То есть будет одно поле name на таблицу. Дополнительные таблицы не нужны. Только не советую в шаблонах выводить данные из поля напрямую, что-то типа $name->ru. Лучше написать хелпер и выводить через него (или трейт для модели). В нем же тогда можно использовать замену из языка по умолчанию если для используемого сейчас языка нет перевода. Будет что-то типа t($name, 'ru')

2) Из основной таблицы убираем все поля для которых нужны переводы в отдельную таблицу переводов для этой таблицы. У нее следующая структура. id, field_name, lang_name( или id), value. Придется писать много кода для реализации удобного сохранение/чтения используя текущую работу с моделями (или как они там в yii2 называются).

По мне лучше первый вариант.

Answer 2

[ThunderCat]

1) Перевести проект на какой-то адекватный движок по типу лары,
2) использовать готовые пакеты мультиязычности, протестированные, с прозрачной логикой и качественной реализацией.

Как вариант - посмотреть в коде готовых мультиланг пакетов как сделать нормально.

Comments

[максим кошкин]

Проект на yii2, пакеты, какие нашёл - рассчитаны на работу как раз с вариантом table + table_lang. Хочу адапитровать под структуру, какую расписал в вопросе