Как поддерживать подход Мультиязыков в Схеме базы данных?

Мне пришлось иметь дело с этим в базе данных допросов. Необходимо было перевести несколько вопросительных знаков на несколько языков (английский, японский, китайский).

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

Так что типичный запрос будет выглядеть следующим образом:

select     p.id
,          pt.product_name
,          pt.product_description
from       product                  p
inner join product_translations pt
on         p.id = pt.product_id
and        'fr' = pt.language_code

Так что для получения переводов всегда достаточно одного дополнительного соединения (для каждой таблицы).

Я должен отметить, что нам пришлось иметь дело только с ограниченным количеством таблиц, так что не было большой проблемой поддерживать несколько дополнительных таблиц %_translations.

Мы рассмотрели возможность добавления столбцов для нового языка, но решили не делать этого по нескольким причинам. Прежде всего, количество поддерживаемых языков было неизвестно, но могло быть существенным (10, 20 или, может быть, больше). В сочетании с тем фактом, что в большинстве таблиц было как минимум 3 отдельных читаемых человеком столбца, нам пришлось бы добавлять много, много текстовых столбцов, в результате чего получились бы очень широкие строки. Поэтому мы решили не делать этого.

Другой подход, который мы рассмотрели, состоит в том, чтобы сделать одну большую таблицу "label", имеющую колонки:

( table_name)( имя_таблицы id_of_table column_name язык translate_text)

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

select     product.id 
,          product_name.translated_text product_name
,          product_description.translated_text product_description
from       product p
inner join translations product_name
on         p.id = product_name.id
and        'product'      = product_name.table_name
and        'product_name' = product_name.column_name
and        'fr'           = product_name.language
inner join translations product_description
on         p.id = product_name.id
and        'product'      = product_description.table_name
and        'product_description' = product_description.column_name
and        'fr'           = product_description.language

как вы видите, в сущности, это что-то вроде схемы "объект-атрибут-значение", что делает запрос обременительным.

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