Какие сущности переводить, а какие — нет с сохранением в таблицу?

Question

[Константин]

Есть таблица, которая хранит категории оценивания:

rateCategory

id_category | name
1                  Вкус
2                  Цвет
3                  Качество

Стоит вопрос о переводе этих слов на другие языки для клиента.

Есть ли смысл создавать отдельную таблицу с переводам:

rateCategoryTranslations
id | lang | name | id_category

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

Answer 1

[Myclass]

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

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

1.на месте слов или тексов будут писаться или сами тексты или например номера или key для последующего поиска в словаре. Т.е. поле считывается из базы, проверяется, есть-ли перевод для этого key, если - да, то используется перевод для определёмнного языка. Нет, ну тогда выдаётся то, что имеется. Из плюсов - В базе данных не надо ничего менять, только в приложении. Минус - иногда потом стоят в базе слова или значения, с которыми на уровне SQL-запросов ничего не возможно сделать.

2. в принципе как и первый вариант, но key не заменяет текст, а само поле превращается в комбинацию из значения и например через како-то набор символов в key, типа значение{key=xxx}. Из плюсов, как и в первом случае. Из минусов - значения в таблицах становятся не тем, для чего они были предусмотрены.

и 1-й и 2-й варианты мне не нравятся, потому что они совмещают в себе то, что не надо - Значения в базе и перевод для клиента. Поэтому предложу 3-й вариант.

3. дополнительно к полям, которые содержат слова или тексты, которые в последствии могут быть переведены - добавить ещё одно, которое содержит key для перевода и для каждого поля со словами для перевода. Т.е. если поле с key пустое, то на стороне клиента ничего не переводится. Если есть что-то, то по крайней мере идёт поиск в словаре.

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

А что я-бы не делал:
- во-первых для одного поля в базе словарь я не писал-бы. Приходит второе поле и что? Ни id не подойдёт или надо дополнительно писать, какая таблица итд.

- также я не писал-бы в одну и ту-же таблицу различные records, но выражающие одно и то-же, но на разных языках. И не важно с одинаковым id или с разным. Язык в клиенте - это язык. С данными продуктов, покупками итд. язык для показа текста ничего общего не имеет.

Надюсь, какая-нибудь из этих мыслей подойдёт.

Answer 2

[Akina]

Количество категорий весьма ограничено. Я бы вообще все положил в одну таблицу:

CREATE TABLE rateCategory (
    category_group INT NOT NULL,    -- группа (категория того-сего) (возможно, также FK)
    category_id INT NOT NULL NOT NULL,  -- идентификатор категории в группе
    category_name_language CHAR(5) NOT NULL,    -- язык наименования (возможно, INT и FK)
    category_name VARCHAR(255) NOT NULL,   -- наименование категории на указанном языке
    PRIMARY KEY (category_group, category_id, category_name_language)
);

Впрочем, на одной таблицы под всё не настаиваю...

Такая структура также позволяет задать и приоритет языков - если перевод на требуемый язык отсутствует, используется вариант на дефолтном языке. Причём приоритет можно задавать общий, для группы, и даже для отдельного термина.

Comments

[Константин]

А зачем category_group INT NOT NULL? т-е вы предлагает хранить все в одной таблице. Я хотел сделать что-то более универсальное. Потому как будет много таких таблиц с переводами

[Akina]

А зачем category_group INT NOT NULL? т-е вы предлагает хранить все в одной таблице.

Ну, во-первых, я совершенно явно об этом говорю.
Во-вторых, я на таком решении совершенно не настаиваю.

Я хотел сделать что-то более универсальное. Потому как будет много таких таблиц с переводами

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

[Myclass]

...вот так-бы я точно никогда не делал. Язык перевода не имеет ничего общего с нумерацией или init-значениями in table. Потому что след. SQL-запрос на эту таблицу для одной категории будет выдавать несколько records - суммирование через SQL уже не идёт. Это первое, а второе - вы используете например какую-ту категию как немецкую или просто катргорию. Т.е. пользование этой category_id в других таблицах несёт за собой и поле category_name_language , без которого не идёт.

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