Здравствуйте, Poul_Ko, Вы писали:
P_K>Как можно создать файл dbschema имея терминальный доступ к серверу БД?
vsdbcmd? Не проверял.
P_K>как удалять объекты из БД? Удаляю файл из Solution Explorer, но после билда в скрипте не появляется инструкции DROP.
Копаемся в настройках скриптогенератора (файл Database.sqldeployment).
P_K>Прошу поделиться опытом
Всё нижесказанное — для "взрослых баз", если у вас база используется чисто для хранения данных вашего приложения, можно спокойно забивать на то, что не нравится.
Деплоймент:
1. Обязательно иметь тестовый сервак, на него деплоить только пересозданием базы. В результате имеете постоянно рабочий deployment script для новых инсталляций.
2. Для деплоймента на боевой сервак генерим скрипт, переносим в management studio, тщательно проверяем, бэкапим, запускаем (или полагаемся на студию/VSDBCMD и надеемся что ничего не сломается).
3. Более мягкий вариант — используем скрипт, сгенерированный schema compare.
В любом случае — скрипт создаётся из проекта, не из тестовой базы.
Для комфортной работы придётся:
1. Обновиться до
GDR R2. По возможности переходить на 2010ю студию, в VSTSDB 2008 множество багофич без шансов на исправление.
2. Активно использовать схемы, именовать файлы в стиле "TableName.table.sql" (без имени схемы). Здорово облегчает работу с большими базами и последующий рефакторинг.
3.
Обязательно упорядочивать объекты по схемам, а не по типу (задаётся при создании проекта, как поменять потом — не разбирался).
4. По возможности работать с проектом через Schema View, поддерживать структуру папок руками нереально.
5. Обязателен vcs и регулярные коммиты — поломать структуру папок можно на раз-два
6. Сразу же озаботиться общим стилем кода — либо приобретать что-то платное (ходят
слухи что кактолькотаксразу выпустят бесплатный автоформаттер), либо писать свои правила для static code analysis. Энфорсить стоит:
— обязательные точки с запятой
— N перед nvarchar-строками
— запрет на deprecated-фичи
— псевдонимы для таблиц
SELECT T.Name
FROM SchemaName.TableName AS T
6. Если ссылаетесь на объекты из master/msdb — обязательно
делать так.
7. Создать проект для сервера, в нём выставить ограничения для деплоймента.
8. Если используете SQLCLR — добавить в солюшн SQLCLR проект,
запретить его деплоить, добавить в VSDB проект как reference, ручками прописать импортируемые объекты. Если сборка
содержит только хелперы, но используется в нескольких базах — сослаться на неё в каждой базе. Если включить сборку только в одну базу, а из остальных баз ссылаться на импортированные методы — геммороя будет несравненно больше, для начала — с циклическими зависимостями.
По дизайну баз.
1. Используем схемы. По возможности не располагаем в одной схеме "внутренние" объекты и объекты, к которым имеет доступ приложение. В результате, разрешения раздаются прямо на уровне схемы, не требуется возиться с отдельными объектами.
2. По возможности избегаем прямого доступа к таблицам, оборачиваем в SP/View.
3. Если вы решили хранить данные в нескольких базах,
не ссылайтесь на объекты в другой базе напрямую. Вместо этого используйте синонимы.
Будут вопросы — приходите ещё
