Лучшие практики использования схем в SQL 2005?

Я использую одну гигантскую схему для всего, поэтому при настройке нового тестового сервера у меня есть только один файл для запуска, и я знаю, что он содержит все необходимое.

Некоторые ORM генерируют один файл для каждого объекта, что, возможно, может помочь в отслеживании изменений? Но я не вижу смысла делать это вручную.

Я пытаюсь использовать его для разделения сфер ответственности в базе данных.

У меня будет схема util / utils / tools, которая довольно переносима между базами данных и имеет таблицу чисел, UDF, SP и другие вещи, которые помогут работать с базой данных. Процедуры не ссылаются ни на что за пределами схемы utils.

Затем у меня будет схема с нуля / работы / времени, в которой я могу выполнить SELECT INTO и создать таблицы, в которых мне нужна настоящая таблица вместо временной таблицы #table. Здесь в основном только таблицы, но возможны также некоторые виды таблиц.

У меня есть полностью отдельная база данных для импорта и результатов тестирования для проверки, но если у вас ее не было, у меня могла бы быть схема import, export и test / testresults, которая содержала те вещи, которые являются ETL или известными хорошими результатами для регрессионного теста против.

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