Многоязычные поля в таблицах БД

Question

У меня есть приложение, которое должно поддерживать многоязычный интерфейс, а точнее, пять языков. Для основной части интерфейса для этого можно использовать стандартный подход ResourceBundle.

Однако база данных содержит множество таблиц, элементы которых содержат человекообразные имена, описания, рефераты и т. Д. Необходимо ввести каждый из них на всех пяти языках.

В то время как я полагаю, я мог бы просто иметь поля для каждой таблицы, как

NameLang1 
NameLang2 
... 

я чувствую, что это приводит к значительному количеству в основном идентичного кода при написании ЗЕРНА представления каждой таблицы.

С чисто объектно-ориентированной точки зрения решение, однако, прост. Каждый класс просто имеет объект Text, который содержит соответствующий текст на каждом из языков. Это также полезно в том, что только один из языков задан, другие имеют правила возврата (например, если на языке 4 отсутствует язык возврата 2, который возвращается к языку 1, который является обязательным).

К сожалению, сопоставление этого вопроса с реляционной базой данных означает, что я завершаю с помощью одной таблицы, что около 10-12 других таблиц FK (некоторые таблицы имеют на самом деле несколько FK).

Этот подход, похоже, работает, и я смог сопоставить данные с POJO с Hibernate. О единственном, что вы не можете сделать, это карта от объекта Text до его родителя (поскольку у вас нет способа узнать, на какую таблицу вы должны ссылаться), но тогда вряд ли нужно это делать.

Итак, в целом это похоже на работу, но просто кажется, что несколько таблиц ссылаются на одну таблицу, как это. Кто-нибудь получил лучшую идею?

Если это имеет значение, я использую MySQL ...

Answer 1

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

В Hibernate вы можете сопоставить информацию из дочерних таблиц как карту и получить информацию о том, какой язык вы хотите, реализуя резервную копию вашего POJO, как вы сказали. У вас могут быть разные геттеры для многоязычных полей, которые внутренне вызывают метод fallback для получения соответствующего дочернего объекта для нужного языка, а затем просто возвращают требуемое поле.

Этот подход использует более таблицы (один дополнительный стол для каждой таблицы, необходимо следующее: информация), но производительность намного лучше, а также техническое обслуживание, я думаю ...

Answer 2

Стандартный перевод подход, используемый для Например, в gettext следует использовать одну строку для описания концепции и сделать вызов метода перевода, который переводит на целевой язык.

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

Answer 3

Подход, который я видел в приложении с аналогичной проблемой, заключается в том, что мы используем столбец «text id» для хранения ссылки, и у нас есть одна таблица со всеми переводами. Это обеспечивает некоторую гибкость при повторном использовании одних и тех же ключей для уменьшения количества требуемых переводов, что является дорогостоящей частью проекта.

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

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

При таком подходе ваших бобов не будут иметь добытчик для каждого языка, но вы бы использовать какой-то другой объект Переводчика:

MyTranslator.translate(myBean.getNameTextId()); 

Answer 4

В зависимости от ваших требований, он может быть лучше иметь отдельную таблицу метки для каждой таблицы, которая должна быть многоязычной. например: у вас есть таблица XYZ с столбцом xyz_id и таблица XYZ_Label с xyz_id, language_code, label, other_label и т. д.

Преимущество этого, имея одну огромную таблицу ярлыков, заключается в том, что вы можете делать уникальные ограничения на таблицу XYZ_labels (например: английское имя для XYZ должно быть уникальным), и вы можете делать индексированные поисковые запросы гораздо эффективнее, поскольку индекс будет охватывать только одну таблицу за раз (например: если вам нужно искать Объекты XYZ по английскому имени).

Answer 5

Что об этом: http://rob.purplerockscissors.com/2009/07/24/internationalizing-websites/ ... это то, что пользователь говорит «Chochos» в ответ # 2