Разработка базы данных MySQL с интернационализацией

Question

Я собираюсь начать работу над приложением среднего размера, и я планирую, что это дизайн БД. В чем я не уверен, так это в следующем. У меня будет много таблиц, которые будут нуждаться в интернационализации, такие как: "members_options, пол_опции, language_options и т. Д."

Каждая из этих таблиц будет иметь общие поля i18n, например: "title, alternative_title, short_description, description"

По вашему мнению, какой способ лучше всего сделать? У вас есть таблица i18n с одинаковыми полями для каждой из таблиц, которая им понадобится?

или сделать что-то вроде:

Membership table     Gender table
----------------     --------------
id | created_at       id | created_at
1  -  22.03.2001       1 - 14.08.2002
2  -  22.03.2001       2 - 14.08.2002


General translation table
-------------------------
record_id | table_name | string_name | alternative_title| .... |id_language
 1        - membership   regular         null                     1 (english)
 1        - membership   normale         null                     2 (italian)
 1        - gender       man             null                     1(english)
 1        -gender        uomo           null                      2(italian)

Это позволило бы мне не повторять что-то вроде:

membership_translation table
-----------------------------
membership_id | name | alternative_title | id_lang
1               regular  null             1
1               normale  null             2

gender_translation table
-----------------------------
gender_id | name | alternative_title | id_lang
1           man     null                1
1           uomo    null                2

и так далее, так что я, вероятно, уменьшил бы количество таблиц БД, но я не уверен в производительности. Я не очень разбираюсь в БД, поэтому, пожалуйста, дайте мне знать.

Answer 1

Самый распространенный способ, которым я видел это, - это две таблицы, membership и membership_ml, одна из которых хранит базовые значения, а таблица ml - локализованные строки.Это похоже на ваш второй вариант.Большинство систем, которые я вижу, сделаны таким образом, потому что они не были спроектированы с учетом интернационализации с самого начала, поэтому дополнительные таблицы _ml были «добавлены» позже.лучший вариант похож на ваш первый вариант, но немного отличается.У вас будет центральная таблица для хранения всех переводов, но вместо того, чтобы помещать туда имя таблицы и имя поля, вы будете использовать токены и центральную таблицу «Содержимое» для хранения всех переводов.Таким образом, если вы хотите, вы также можете принудительно установить некоторый RI-код между токенами в базовой таблице и переводами в таблице содержимого.Некоторое время назад, так что вы можете взглянуть на это для получения дополнительной информации (вместо того, чтобы переписывать примеры схемы здесь).

Answer 2

Я также думаю, что лучшее решение - хранить переводы на разных столах. В этом подходе используется открытая корзина с открытым исходным кодом, и вы можете посмотреть, как она решает проблему. Другой источник информации здесь "http://www.gsdesign.ro/blog/multilanguage-database-design-approach/", особенно в разделах комментариев