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

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

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

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

NameLang1
NameLang2
...

Мне кажется, что это приводит к значительному объему идентичного кода при написании bean-компонентов, представляющих каждую таблицу.

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

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

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

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

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

4 голоса | спросил Kris 2 J0000006Europe/Moscow 2009, 01:41:02

3 ответа


0

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

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

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

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

 MyTranslator.translate(myBean.getNameTextId());
ответил Mario Ortegón 2 J0000006Europe/Moscow 2009, 02:06:28
0

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

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

ответил Chi 2 J0000006Europe/Moscow 2009, 08:32:56
0

Как насчет этого:

ответил olagato 7 MaramSun, 07 Mar 2010 10:12:22 +03002010-03-07T10:12:22+03:0010 2010, 10:12:22

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132