timdaВопрос больше в плоскости производительности ...
Думаю 200-300 таблиц для одной базы на одной схеме dbo - это не страшно, но больно уж неудобно.Неудобно в смысле производительности?
timdaУ меня в голову вбито так - чем меньше БАЗ на сервере, тем лучше, в идеале одна. Что поменялось сейчас?Это как "сколько переменных в идеале должно быть в программе"?

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

timdaЦель у меня какая - разделить базу 10-лет отроду и новую базу, с прицелом на полный переезд в новую.
Грубо говоря - пишу новое приложение к сайту.
Но без старой базы пока никак.Да, вот это хорошая причина "разделить".

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

Например, новое приложение заменяет старое, новое приложение будет работать параллельно со старым, но со своими данными, новое приложение будет работать параллельно со старым, с теми же данными.
Вот надо сначала сделать такую постановку задачи.

timdaмеж-базное взаимодействие на уровне запросов интересно.
в оракле у них по схемам можно упростить себе жизнь. у них там с этим и проблем нет.
может я просто не знаю как по owner у нас можно упростить себе жизнь.У МС и Оракла разные подходы. Хотя в MSSQL тоже есть "схемы", но, по сути, аналог оракловских схем в MSSQL - это базы, а аналог оракловских баз в сиквеле - это инстансы.
И в общем да, можно делить систему на модули, делая разне базы, хотя практический смысл в этом будет в очень редких случаях.

В данном случае, это как делать софт в виде множества dll или exe, потому что в функции слишком много переменных :-)

Что бы не мучаться со списком из 170 таблиц, нужно разрабатывать не в средстве администрирования (SSMS), а в средстве разработки (например, Visual Studio), деля проект на модули и всё такое. Дополнительно нужно принять систему именования объектов, или использовать схемы (но больше для удобства администрирования/сопровождения, а не разработки).
А само по себе стремление "уменьшить количество таблиц" приведут только к снижению производительности и усложнению разработки, хотя программисты без опыта работы уверены, что наоборот.

Понятно, в данном случае ваш вопрос о доступе к старой базе, но это было так, отвлечённое замечание по поводу 170 таблиц - как бы у вас не получилось больше, к тому моменту, когда программа будет реально использоваться бизнесом :-)
timdaМожно много обсуждать архитектуру и варианты, меня интересует лишь проблемы при запросах

select u1.ID, u1.Name
from
old_db.dbo.user u1
left join new_db.dbo.user u2 on u1.ID = u2.OLD_ID

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