Гаджимурадов РустамДа ладно, на деле сотен схем не бывают.
А к трем-четырем быстро привыкаешь и ориентируешься.
с десятком схем работал лично - жить можно, но больше уже пожалуй будет не очень комфортно

Гаджимурадов РустамСхемы для разных целей могут использоваться - например, иметь почти
одинаковые структуры для разного наполнения (а-ля белый и чёрный учёт)
или development и production одной и той же базы. Могут для разного, конечно же. Вопрос нужно ли, поэтому см. выше про здравый смысл. Лично мне это видится через призму связанности, но спорить не буду.

Dimitry SibiryakovТогда будем говорить предметно: вот есть у меня конфигурация репликации - несколько
таблиц, где, собственно, хранятся данные и (предположим) набор ХП для её изменения,
управления и т.п. Сейчас всё это барахло лежит в отдельной БД, но я хочу запихнуть его
непосредственно в реплицируемую БД. Процедуры я, конечно, могу сложить в пакет, но без
таблиц они не имеют смысла. А таблицы в пакет не положишь. И при этом они весьма слабо
связаны с пользовательскими чтобы валяться между ними. Т.е. лично мне идеально подошла бы
отдельная схема. Но тогда и всплывает вопрос "зачем пакеты, когда есть схемы". Что такого
я могу сделать с пакетом, чего не получится со схемой?..

ключевая фраза - "сейчас лежит в отдельной БД". Т.е. к базе юзера твои настройки репликации относятся чисто логически и база без них спокойно продолжит свое существование. Поэтому мой ответ - отдельная схема. Но можно зайти и с другой стороны - если у клиента несколько реплицируемых баз, то у тебя конфигурационных баз тоже несколько или все же одна? Если первое, то IMHO это скорее недостаток проектирования. Но если без этого никак, тогда придется включать объекты в юзерскую схему. Иначе опять же напрашивается отдельная схема.

грубо говоря, представь две абсолютно разные базы, залитые как разные схемы в одну БД. Представь (в перспективе) отдельный бекап-рестор каждой схемы. Подумай, должна ли твоя конфигурация намертво "прилипать" к юзерской схеме при миграциях или дануегонах.