Локализация базы данных

Question

Я ищу мнения, если следующая проблема может иметь лучшее / другое / общее решение:

---

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

В настоящее время у меня есть эта настройка:

Таблица продуктов

CREATE TABLE products
(
  id serial NOT NULL,
  "name" character varying(255) NOT NULL,
  CONSTRAINT products_pkey PRIMARY KEY (id)
)

и таблица локализации продукта

CREATE TABLE products_l10n
(
  product_id serial NOT NULL,
  "language" character(2) NOT NULL,
  "name" character varying(255) NOT NULL,
  CONSTRAINT products_l10n_pkey PRIMARY KEY (product_id, language),
  CONSTRAINT products_l10n_product_id_fkey FOREIGN KEY (product_id)
      REFERENCES products (id) MATCH SIMPLE
      ON UPDATE CASCADE ON DELETE CASCADE
)

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

SELECT p.id, COALESCE(pl.name, p.name) 
from products p LEFT 
JOIN products_l10n pl ON p.id = pl.product_id AND language = 'de';

Код SQL написан на диалекте postgres. Данные хранятся в формате UTF-8.

Answer 1

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

CREATE TABLE products_l10n
(
  product_id serial NOT NULL,
  language_id int NOT NULL,
  "name" character varying(255) NOT NULL,
  CONSTRAINT products_l10n_pkey PRIMARY KEY (product_id, language),
  CONSTRAINT products_l10n_product_id_fkey FOREIGN KEY (product_id)
      REFERENCES products (id) MATCH SIMPLE
      ON UPDATE CASCADE ON DELETE CASCADE
  CONSTRAINT products_l10n_language_id_fkey FOREIGN KEY (language_id)
      REFERENCES languages (id) MATCH SIMPLE
      ON UPDATE CASCADE ON DELETE CASCADE
)

CREATE TABLE languages
)
  id serial not null
  "language" character(2) NOT NULL
)

Кроме того, я думаю, что у вас есть самое лучшее решение.

Answer 2

Единственный вариант, который я могу предложить, это то, что вы также можете включить возможность выбора страны / диалекта; Например, вместо английского (en), используйте английский US (en-US). Таким образом, вы можете полностью учитывать вариации (например, британское написание, французский канадский, вероятно, отличается от французского, на котором говорят во Франции и т. Д.).

Answer 3

Выглядит хорошо - похоже на мою любимую технику локализации - как насчет широких символов (японский)? Мы всегда использовали nvarchar для этого.

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

Answer 4

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

Тогда я получаю такой запрос:

SELECT 
    i.id, 
    i.price, 
    it.label 
FROM 
    items i 
    LEFT JOIN items_trans it 
        ON i.id=it.item_id AND it.lang_id=(
            SELECT lang_id
            FROM items_trans
            WHERE item_id=i.id
            ORDER BY
                (lang_id=1) DESC,
                (lang_id=0) DESC
            LIMIT 1
        )

Что ты думаешь?

Answer 5

Единственный усложняющий фактор, о котором другие не упомянули, это наборы кодов - сможете ли вы работать с ивритом, арабским, русским, китайским, японским? Если все в Unicode, вам нужно беспокоиться только о GB18030 (китайский), который (IIUC) является расширенным набором Unicode.

Answer 6

выглядит прилично для меня.

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