Ребята, у меня такой вопрос. Работаю над проектом где потребуется

мультиязычность организовывать для ключевых таблиц в бвзе данных.
У меня возникла идея.
Я хочу в самой таблице хранить битовое поле (число): где каждый бит будет означать некий язык, и соответственно проверять то для каких языков существуют данные для этой записи, а сами переводы текстов хранить в отдельной таблице, где: будет форейн кей на саму сущность, и ключ уникальный по language_code , entity_id
Как вам идея ? Как вы обычно организовываете мультиязычность ?

Очень плохая идея

Организуется легко, связь один кол многим от каждой таблицы с атрибутами , требующими перевода, к таблице перевода, где pk состоит из полей pk основной таблицы плюс код языка

Я не дочитал, сорри. Идея ок, КРОМЕ битового поля наличия переводов. Это и нарушение 1НФ , и ещё и дублирование данных. Признак наличия перевода и так есть в таблице переводов, это поле не нужно

в данном случае помоему можно пренебречь 1НФ, потому что это ж по сути кеш (условный), который будет заполняться один раз, при редактировании данных в админке. Вместо того чтобы делать постоянно запрос по связанной таблице. Своего рода такая денормализация данных

А зачем он ?

Ты в курсе, что ты никаким индексом это поле с битовой маской языков не покроешь? А там, в связанной таблице — пожалуйста, строй индексы, делай запросы...

гм, тему индексов пока не исследовал, надеялся что будет какой то воркэраунд

Не надейся. Нарушение 1НФ — нахер с пляжа, НОЛЬ индексов...

Почему и говорю всегда, нарушение 1НФ — страшнейшая ошибка в проектировании!

спасибо за подсказку

Покроешь. В постгресе есть индэксы, которые покроют битовые маски.

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

если вам интересно, то можете посмотреть как это реализованно в ERP от oracle - OEBS. если в кратце, то там есть поле language

Этот по сути кэш тебе ничего не сможэт ускорить. Поскольку если тебе нужна строка — то всё равно обращать ся по индэксу во вторую таблицу. И правильный индэкс там будет (идтекста, язык) — и список доступных языков будет получаться index range scan этих нескольких записей на одной несчастной страницэ. К которой тебе всё равно обращаться. Зато геморроя и тормозов это можэт добавить. Геморроя — в рамках синхронизацыи, тормозов — поскольку любое добавление перевода будет блокировать запись в основной таблицэ/создавать новую версию этой записи.

Так это везде примерно так вот и реализовано.

Это да, если просто упомянуть ERP от Oracle, то на него можно найти ссылку, которую запостил выше. у них в доке все довольно хорошо расписанно