@bezdealnick

Мультиязычность со значением по-умолчанию. Есть ли другое решение?

Сайт должен поддерживать мультиязычность, для себя выбрал решение такое: таблица, которая требует переводы, имеет доп. таблицу с префиксом _i18n, в них хранятся общие значения, которые должны быть на нескольких языках. Но столкнулся такой проблемой, которую не могу решить посредством одного запроса. Клиенту важно, чтобы информация выводилась на языке по-умолчанию, если она не заполнена на выбранном пользователем языке. Поиск, чтобы работал аналогично, если значение заполнено, ищет по нему, если нет, то в языке по-умолчанию.
Чтобы данные всегда выходили, независимо от перевода, написал такой запрос (для примера):
SELECT
    region.*,
    COALESCE(sLang.name, dLang.name) as name
FROM
    region
LEFT JOIN region_i18n AS sLang ON sLang.region_id = region.id AND slang.lang_id = 2
LEFT JOIN region_i18n AS dLang ON dLang.region_id = region.id AND dLang.lang_id = 1

И всё выводится корректно, даже если название области не имеет перевода, то выводится на языке по-умолчанию. Но, как быть с поиском при таком запросе? Практически для всех запросов, у меня всегда хватало where, здесь оно работать не хочет. Когда делаю запрос с WHERE name LIKE '%Крас%', он пишет ошибку, что такого столбца не существует. Нашел выход для фильтрации через HAVING name LIKE '%Крас%', тогда все ищется нормально. Не возникнет ли проблем, при большом кол-ве данных с такими запросами? Плюс, на данный момент я использую COALESCE(sLang.name, dLang.name) as name чтобы вытянуть данные на первом языке, в котором есть значение. Получается для каждого переводимого поля, мне нужно его использовать. В некоторых таблицах может быть 5-10 таких полей, сильно ли повлияет на производительность такая выборка?
  • Вопрос задан
  • 71 просмотр
Пригласить эксперта
Ответы на вопрос 1
BojackHorseman
@BojackHorseman Куратор тега SQL
...в творческом отпуске...
WHERE и HAVING не одно и то же. собственно поэтому алиас name недоступен в первом случае и доступен во втором. но решать вопрос таким костылем - сильно бить по производительности.
хотя тут в любом случае будет медленно. like по вычислимому полю, всегда мимо индексов. не годится.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы