roman_lenko таблица dbo.User одна в неизменном виде, а вот таблиц dbo.City должно быть несколько: одна версия с русскими названиями городов, вторая, пускай, с английскими названиями тех же городов с теми же идентификаторами. Это нужно для того, чтобы можно было извлекать данные пользователя как с русскими названиями городов, так и с английскими. ПРИЧЁМ, dbo.City на русском будет находится в одной базе данных, а dbo.City на английском — в другой базе данных; при этом dbo.User должна быть общей для обоих баз данных — как это реализовать?

1) Самый брутальный вариант — держать 2 копии таблицы dbo.User в обоих базах данных, но таким образом мне необходимо будет данные в 2-х таблицах синхронизировать, а это значит нужно писать систему синхронизации, чего делать мне не хочется.

2) Второй вариант, держать в базе данных 2 таблицы городов: dbo.CityRUS и dbo.CityENG и уже, в зависимости, например от какого-то передаваемого в запрос параметра с идентификатором языка, выполнять переключение в дуже SWITCH:




Но, я считаю, что это извращение.


Правильно считаешь.
Никаких двух баз, никаких двух таблиц быть не должно.


автор3) Вариант — сделать так, чтобы в таблице городов хранились и русские и английские названия в разных колонках — не вариант, потому, что БД желательно разместить на разных серваках — из-за неоднородности нагрузки исходящей от клиентов, которые используют английские и русские названия городов.


Ты прав, не вариант.

Решается достаточно просто , в общем, есть два варианта.

Либо к каждой таблице, где храняться переводимые данные, ты делаешь таблицу с суффиксом (или префиксом) , например, "_INT"
или "_TRANS", где таблица состоит из:

полей PK изначальной таблицы

добавленного в PK идентификатора языка (лучше в виде текстовой константы -- кода языка типа 'RU' 'EN' и т.д.)

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

Таким образом, у тебя получается таблица один-ко-многим с основной, в которой хранятся переводы данных основной таблицы на разные языки.

Использование очевидно:





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

PK -- ид сущности, ид атрибута сущности, ид экземпляра сущности, ид языка. Атрибут один -- значение атрибута на данном языке.

Запросы аналогичны, только ещё константами будут задаваться ид сущности и ид атрибута сущности.

roman_lenkoНо, я считаю, что это извращение.


Роман, кстати хочу отметить особо, что очень здорово , что у тебя сразу возникло такое чувство.
Это значит, у тебя есть правильное реляционное мышление, ну или хотя бы его задатки.