Подвалы Вавилонской башни, или Об интернационализации баз данных с доступом через ORM

[dem0n3d]

А не рассматривали вариант представлений (View)? Не проще ли их интегрировать в ORM?

[vlio]

Таблицы или представления — нет разницы для использования с ORM, объема трафика, цены запросы и пр. Разве что, использовать хранимые (материализованные) view.

[Dansoid]

Вам надо было попробовать linq2db
Там и не такое можно сгенерировать. Практически любой полет фантазии реализуем. EF Core, скорее всего не выпустит вас за свои рамки, а они очеь строгие.

[vlio]

Конечно, EF жесткий.
В статье специально рассмотрены только два самых популярных ORM на .NET. А для боевого проекта при выборе технологии сыграют роль не только гибкость, но и множество факторов, в том числе распространенность, размер комьюнити. https://goo.gl/2LP128

[Dansoid]

Так расширяйте это комюнити, а не двигайтесть за толпой ;)
Я как один из разработчиков linq2db, скажу что у вас не проблема, а проблемка.
Ассоциации любой сложности, ремаппинг полей на лету и гибкая раширяемость.
Огромное количество юнит тестов гарантируют что все это будет работать и через 10 лет.
А по скорости… перед нами только ручной маппер.

[vlio]

Не ставлю под сомнение гибкость вашего фреймворка :)

Так расширяйте это комюнити, а не двигайтесть за толпой ;)
Ну это лозунг. Цель проекта как правило не в этом. Архитектурные решения, в том числе выбор технологий — часто связаны с рисками и/или компромиссами. Требования в боевых проектах разнятся и, быть может, linq2db в последующих проектах попадет в шорт-лист при выборе.

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

[Dansoid]

Да и не думаю ;)
Но похоже часто нужны шашечки вместо того чтобы ехать.

[michael_v89]

SQL-запроc с учетом поиска подходящих локализаций уже более громоздкий
Соединения с таблицей t_product_localizable можно заменить на подзапросы, но это принципиально ничего не меняет.

А нельзя на 2 запроса разбить? И собрать их в коде или через JOIN с GROUP BY?

SELECT id_product, name
FROM t_product_localizable
WHERE locale IN ('ru', 'en') AND name LIKE @p1

SELECT id_product, code
FROM t_product
WHERE id_product IN (@p1)

[vlio]

Фактически такой подход — это ленивая загрузка многоязычного атрибута. Два раундтрипа для единичной сущности обычно дороже, чем JOIN или подзапросы. Но реализуемость для этого варианта не проверял.