Проектирование БД для многоязычного проекта

#база_данных #postgresql

Мой мозг, размягченный NoSQL, совсем отказывается проектировать нормальную реляционную БД.

Задача такова:


Есть сущности: карточки, теги, категории. Возможно, позже появится что-то еще;
У каждой сущности есть связи, которые не зависят от языка;
У каждой сущности есть текстовые поля, которые надо переводить (количество языков
не велико, в начале проекта будет 2, позже добавится еще 2-3).


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

Стек технологий проекта: PostgreSQL, SQLAlchemy, Flask 

UPDATE

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

Ответы

Ответ 1

Набор языков фиксированный? Если да, добавляйте локализованные поля к полям, которым
нужен перевод, постфиксы *_ru, *_en и т.д.

Если нет - создайте что нибудь типа translation: id, key, value - и используйте ссылки
на них, вместо прямых значений полей.


Ответ 2

Есть множество решений, могу предложить одно, которое можно легко присоединять в
одном запросе как пример в MySQL (JOIN)

Есть таблица как основная с карточками, у неё структура примерно такая:

cards - ID | COLOR | VIEWS | CREATED


И есть вспомогательная таблица с переводами

card_languages - ID | CARD_ID | LANGUAGE | NAME | DESCRIPTION


ну и как пример в MySQL:

SELECT a.*, b.name, b.description FROM cards a LEFT JOIN card_languages b ON b.card_id=a.id
WHERE b.langauge=1


Ответ 3

В нашем проекте, рассмотрев несколько вариантов, остановились на том, чтобы хранить
многоязычные данные в виде XML.

В нашем случае речь шла о MS SQL, но Postgres, как я вижу, тоже понимает XML-поля.

Из явных минусов — невозможность индексирования по таким полям, и отсутствие поддержки
оператора LIKE 'prefix%'. Полнотекстовый поиск всё же возможен (хотя объём такового
для PostgreSQL оценить не берусь).

Ещё один минус — необходимость поддерживать такие поля с помощью уровня предметной
области (то есть такие поля труднее читать и править вручную).


Ответ 4

Подсмотрел подходящее решение здесь.

Для каждой карточки сделать отдельную таблицу с переводом:

CREATE TABLE T_PRODUCT (pr_id int, PRICE NUMBER(18, 2))

CREATE TABLE T_PRODUCT_tr (pr_id INT FK, languagecode varchar, pr_name text, pr_descr
text)


Карточка собирается одним простым джоином. FallBack по языкам сделать правда сложнее,
но для задачи и не требовалось.