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

Как указано там , вы не можете добавить символ ? в vim после звездочки. Чтобы сделать поиск не жадным, вам нужно использовать .\{-} вместо .*:

:%s/\(.\{-}\)here//

10
задан Fionn 10 October 2008 в 00:38
поделиться

6 ответов

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

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
)

Помимо этого, я думаю, что у Вас есть примерно самое лучшее решение.

6
ответ дан 4 December 2019 в 02:27
поделиться

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

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

1
ответ дан 4 December 2019 в 02:27
поделиться

Выглядит достойным мне.

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

0
ответ дан 4 December 2019 в 02:27
поделиться

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

1
ответ дан 4 December 2019 в 02:27
поделиться

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

0
ответ дан 4 December 2019 в 02:27
поделиться

Имея дело с подобными вещами, я использую для создания таблицы product, не содержащей вообще никакого имени, и таблицы 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
        )

Что вы думаете?

0
ответ дан 4 December 2019 в 02:27
поделиться
Другие вопросы по тегам:

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