Здравствуйте, товарищи!
Попытаюсь максимально доходчиво объяснить свою проблему с помощью простых примеров «на пальцах».
Итак, например, есть таблица пользователей:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
create table dbo.User(
-- ID пользователя.
int id,
-- Имя пользователя.
varchar name,
-- ID города пользователя.
int cityId foreign key references dbo.City(id)
);
Соответственно, есть таблица городов (для вышеуказанных пользователей):
1.
2.
3.
4.
5.
6.
7.
8.
create table dbo.City(
-- ID города.
id int,
-- Имя города.
varchar name
);
Есть простой запрос с JOIN'ом, который излекает все данные пользователя, заменяя идентификатор города на название города.
1.
select * from dbo.User as User left join dbo.City as City on User.cityId = City.id where id = 1;
А теперь представим эту базу данных в контексте работающего сайта. И не просто сайта, а сайта мультиязычного, где
(тут внимание!) : таблица dbo.User одна в неизменном виде, а вот таблиц dbo.City должно быть несколько: одна версия с русскими названиями городов, вторая, пускай, с английскими названиями тех же городов с теми же идентификаторами. Это нужно для того, чтобы можно было извлекать данные пользователя как с русскими названиями городов, так и с английскими. ПРИЧЁМ, dbo.City на русском будет находится в одной базе данных, а dbo.City на английском — в другой базе данных; при этом dbo.User должна быть общей для обоих баз данных — как это реализовать?
1) Самый брутальный вариант — держать 2 копии таблицы dbo.User в обоих базах данных, но таким образом мне необходимо будет данные в 2-х таблицах синхронизировать, а это значит нужно писать систему синхронизации, чего делать мне не хочется.
2) Второй вариант, держать в базе данных 2 таблицы городов: dbo.CityRUS и dbo.CityENG и уже, в зависимости, например от какого-то передаваемого в запрос параметра с идентификатором языка, выполнять переключение в дуже SWITCH:
1.
2.
3.
4.
5.
6.
7.
SWITCH langId:
case "RUS":
select ... join on dbo.CityRUS.id;
break;
case "ENG"
select ... join on dbo.CityENG.id;
break;
Но, я считаю, что это извращение.
3) Вариант — сделать так, чтобы в таблице городов хранились и русские и английские названия в разных колонках — не вариант, потому, что БД желательно разместить на разных серваках — из-за неоднородности нагрузки исходящей от клиентов, которые используют английские и русские названия городов.
Может есть какое-то просто и быстрое решение, до которого я просто не могу додуматься?
Также, сразу хочу отметить, что я против использования динамических SQL-запросов (ну, естественно, кроме ситуаций, где без них никак) — т.е., только хранимые процедуры.
Спасибо!
Роман.
