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

Под него еще положить индекс для группировки по (язык, ид ресурса) и все будет путем...

Хотя... из линк-то-скл нужного добиться будет сложно...

Добавлять новый язык будет не так просто.

Зависит от реализации. Установив правила имен таблиц, новый язык можно добавлять путем добавления соответствующей таблицы в БД :)

Потому что менеджер явно на стороне приложения.

Менеджер просто генерит запрос: $"SELECT * FROM Translation_{cultureInfo.TwoLetterISOLanguageName} WHERE Id = {id}"

Если хочется, то можно сразу джойнить английскую (дефолтную) строку.

Угу... А во что выльется добавление еще одного языка?

В добавление еще одной таблицы. Даже код менеджера не надо править :)

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

Мы это все делали на SQLite.

В добавление еще одной таблицы.

-----

Ээээ... как бы это помягче сказать...

на SQLite

-----

... предоставляемые возможности определяют.

Но это не означает что решение можно брать за образец.

А зачем тут 2 таблицы

А количество таблиц не считали и работу по добавлению нового языка?