Лучшие практики для использования схем в SQL 2005? - PullRequest
2 голосов
/ 17 января 2009

Мы планируем переместить базу данных SQL 2000 в SQL 2005, и я знаком со способностью в 2005 году создавать таблицы или другие объекты под различными владельцами / схемами.

У нас не было такой возможности в SQL 2000, поэтому мне интересно, каковы будут мои рекомендации / рекомендации по созданию / управлению несколькими схемами.

Должен ли я создать одну схему для всех объектов? Как мне их разделить?

Ответы [ 2 ]

3 голосов
/ 17 января 2009

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

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

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

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

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

0 голосов
/ 17 января 2009

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

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

...