ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Как реализуют многоязычность в БД?
7 сообщений из 7, страница 1 из 1
Как реализуют многоязычность в БД?
    #39180771
kormot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kormot
Участник
Добрый день!

Хочу узнать, как лучше и удобней всего реализовывать в БД поддержку интернационализации для наименований?

Я пока реализовал это таким способом:
Код: sql
1.
2.
3.
4.
5.
Table Items (
   id       SERIAL,
   l10_data TEXT NOT NULL,
   srchIdx  TEXT NOT NULL
)


где в l10_data лежит сериализованный массив:
Код: php
1.
2.
3.
4.
5.
Array(
   "ru"  => "Наименование объекта",
   "en" => "Object name",
 .......
)


а в srchIdx кладётся конкатенация всех этих элементов массива, для организации поиска по этому полю.

Подскажите примеры как реализуют правильно и красиво в БД хранение объектов с переводами содержимого на разные языки.
Думал хранить в виде связаной таблицы:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
Table Items (
   id     SERIAL
)

Table Items_l10 (
   id       SERIAL,
   itemID   SERIAL,
   langCode CHAR(2),
   data     CHAR(255),
   FK(itemID) => Items(id)
)


Или с помощью длинной таблицы:
Код: sql
1.
2.
3.
4.
5.
6.
Table Items (
   id      SERIAL,
   ru_data CHAR(255),
   en_data CHAR(255),
 .......
)


Но с вариант с доп. таблицей вроде подразумевает дофига JOIN'ов причём в условиях, когда не обязательно что перевод есть. И это либо LEFT JOIN либо всякие NULL'ы обрабатывать. А вариант с разреженой таблицей - так запросы строить один гемор.

Вобщем как это на практике чаще всего делается?
...
Рейтинг: 0 / 0
28.02.2016, 12:51
| Ответить | Цитировать | Написать  
Как реализуют многоязычность в БД?
    #39180887
kormot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kormot
Участник
Сам по форуму посмотрел, такие топики уже неоднократно возникали и собственно два варианта и предлагаются всегда.

Я же для себя понял, что оставлю комбинацию моего "сериализованного" варианта и варианта с доп. таблицей в которой перевод лежит по ключу: (itemID, langCode).
Просто для повседневного использования проще использовать "сериализованный" вариант. Не надо связывания дополнительной таблицы. Но чтобы сам перевод делать, надо как минимум получить информацию о том какие элементы на какие языки ещё не переведены. И это из сериализованного варианта кроме как через чёрный ход не получить. Для осуществления самой функции перевода нужна таблица в которой отдельные переводы и будут. А уже при её наполнении будет обновляться запись в сериализованной таблице.

Спасибо.
...
Рейтинг: 0 / 0
28.02.2016, 17:56
| Ответить | Цитировать | Написать  
Как реализуют многоязычность в БД?
    #39180899
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
kormot,

таблица

(сущность, идентификатор, язык -> название)

или другой вариант

к каждой таблице, где нужны переводы - еще одна,

(pk основной таблицы, язык -> атрибут1,атрибут2 ...)

все.
...
Рейтинг: 0 / 0
28.02.2016, 18:05
| Ответить | Цитировать | Написать  
Как реализуют многоязычность в БД?
    #39180903
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
kormot?

Я пока реализовал это таким способом:
Код: sql
1.
2.
3.
4.
5.
Table Items (
   id       SERIAL,
   l10_data TEXT NOT NULL,
   srchIdx  TEXT NOT NULL
)


где в l10_data лежит сериализованный массив:
[src PHP]
Array(
"ru" => "Наименование объекта",
"en" => "Object name",
.......
)



так нельзя, нарушение 1НФ, это все нельзя будет обрабатывать запросами.
...
Рейтинг: 0 / 0
28.02.2016, 18:08
| Ответить | Цитировать | Написать  
Как реализуют многоязычность в БД?
    #39180908
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
kormotНо с вариант с доп. таблицей вроде подразумевает дофига JOIN'ов причём в условиях, когда не обязательно что перевод есть. И это либо LEFT JOIN либо всякие NULL'ы обрабатывать. А вариант с разреженой таблицей - так запросы строить один гемор.


куча join-ов не проблема, это недорогая операция.
если тебе геморрой писать запросы или выражения в них -- так что ты полез в базы данных их писать? Доверь это дело профессионалам!
...
Рейтинг: 0 / 0
28.02.2016, 18:14
| Ответить | Цитировать | Написать  
Как реализуют многоязычность в БД?
    #39180976
kormot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kormot
Участник
MasterZivтак нельзя, нарушение 1НФ, это все нельзя будет обрабатывать запросами.
Так а если это поле для удобства использования данных в приложении?
А таблица связаная в которой находятся данные по ключу (objectID, langCode) тоже присутствует и сериализованные данные для объекта обновляются в случае внесения изменений в таблицу с переводами.

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

Тут в моём варианте и нормальная форма имеется для правильного логического хранения, а l10_data это для устранения необходимости для каждой таблицы джойнить переводы, да ещё с проверкой а есть ли нужный перевод и если его нет, то сджойнить ещё перевод по умолчанию.
Я в общем выбор сделал, спасибо!
...
Рейтинг: 0 / 0
28.02.2016, 21:18
| Ответить | Цитировать | Написать  
Как реализуют многоязычность в БД?
    #39186364
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
kormotMasterZivтак нельзя, нарушение 1НФ, это все нельзя будет обрабатывать запросами.
Так а если это поле для удобства использования данных в приложении?


Это можно делать только в одном случае -- если внутри БД (т.е. и в запросах к ней) это поле будет только читаться (целиком) или писаться (целиком).
Но я лично в это не верю.
Клиенстскому приложению всё равно, как получить эти данные, так или иначе, а вот внутри БД лучше иметь их в нормальном виде.

kormotJOIN не проблема, так вроде пишут что множество JOIN'ов это как раз причина медленных запросов и для этого как решение всегда предлагают в разумных пределах делать денормализацию базы.


Послушай дебилов -- и сделай наоборот, не ?

kormotТут в моём варианте и нормальная форма имеется для правильного логического хранения, а l10_data это для устранения необходимости для каждой таблицы джойнить переводы, да ещё с проверкой а есть ли нужный перевод и если его нет, то сджойнить ещё перевод по умолчанию.
Я в общем выбор сделал, спасибо!
Поздравляю, главное, чтобы он был правильным!
...
Рейтинг: 0 / 0
05.03.2016, 12:31
| Ответить | Цитировать | Написать  
7 сообщений из 7, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Как реализуют многоязычность в БД?
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=32&msg=39180976&tid=1540385]:
 0ms
get settings:
 9ms
get forum list:
 18ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 52ms
get topic data:
 10ms
get forum data:
 2ms
get page messages:
 46ms
get tp. blocked users:
 2ms
others: 247ms
total:  392ms
созд. / загр.: 392ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]