Хотелось бы узнать способы организации работы при разработке и поддержке базы данных.
Итак, имеется БД на MS SQL Server 2008. БД содержит множество схем, таблиц, представлений, функций и хранимок. Количество задействованных разработчиков невелико — 2-3 человека. Боевая база крутиться далеко (доступ по терминалу). Основная работа ведётся над хранимками/функциями, иногда изменяется (в основном дополняется) структура таблиц. Обновления небольшие, выходят с периодичностью в несколько дней.
Сейчас используется такая схема работы: все работают в Management Studio над одной базой, иногда отдельный разработчик разворачивает свою копию базы. Все сделанные изменения сохраняются в виде sql-скриптов, для обновления боевой базы эти скрипты запускаются последовательно вручную.
Недостатки очевидны:
— необходимо не забыть все сделанные изменения сохранять в виде скриптов
— неудобно "накатывание" изменений в виде ручного запуска десятка sql-скриптов
— не используется система контроля версий
Решил попробовать Visual Studio 2008 Database Edition: поставил поддержку SQL Server 2008, создал проект, импортировал существующую базу. Система контроля версий (используем bazaar) работает на ура.
Имеется ряд вопросов:
— скрипт обновления схемы боевой базы из разработческой создаётся с помощью Schema Comparison? Для этого нужна сама боевая база или её схема в виде файла dbschema. Как можно создать файл dbschema имея терминальный доступ к серверу БД?
— как удалять объекты из БД? Удаляю файл из Solution Explorer, но после билда в скрипте не появляется инструкции DROP.
Прошу поделиться опытом и дать советы по организации работы в нашем случае.
Здравствуйте, 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-фичи
— псевдонимы для таблиц
SELECTT.Name
FROM SchemaName.TableNameAS T
6. Если ссылаетесь на объекты из master/msdb — обязательно делать так.
7. Создать проект для сервера, в нём выставить ограничения для деплоймента.
8. Если используете SQLCLR — добавить в солюшн SQLCLR проект, запретить его деплоить, добавить в VSDB проект как reference, ручками прописать импортируемые объекты. Если сборка содержит только хелперы, но используется в нескольких базах — сослаться на неё в каждой базе. Если включить сборку только в одну базу, а из остальных баз ссылаться на импортированные методы — геммороя будет несравненно больше, для начала — с циклическими зависимостями.
По дизайну баз.
1. Используем схемы. По возможности не располагаем в одной схеме "внутренние" объекты и объекты, к которым имеет доступ приложение. В результате, разрешения раздаются прямо на уровне схемы, не требуется возиться с отдельными объектами.
2. По возможности избегаем прямого доступа к таблицам, оборачиваем в SP/View.
3. Если вы решили хранить данные в нескольких базах, не ссылайтесь на объекты в другой базе напрямую. Вместо этого используйте синонимы.
Будут вопросы — приходите ещё
Re[2]: Организация работы над MS SQL 2008 DB Project
Здравствуйте, Sinix, Вы писали:
P_K>>Как можно создать файл dbschema имея терминальный доступ к серверу БД? S>vsdbcmd? Не проверял.
Да, похоже оно. К тому же легко переносится на другую машину отдельно от студии.
P_K>>как удалять объекты из БД? Удаляю файл из Solution Explorer, но после билда в скрипте не появляется инструкции DROP. S>Копаемся в настройках скриптогенератора (файл Database.sqldeployment).
О, точно! Есть такая опция. S> S>Деплоймент: S>1. Обязательно иметь тестовый сервак, на него деплоить только пересозданием базы. В результате имеете постоянно рабочий deployment script для новых инсталляций.
Разве из проекта нельзя создать скрипт для новой инсталляции? Или у этого тестового сервера иная цель?
S>2. Для деплоймента на боевой сервак генерим скрипт, переносим в management studio, тщательно проверяем, бэкапим, запускаем (или полагаемся на студию/VSDBCMD и надеемся что ничего не сломается). S>3. Более мягкий вариант — используем скрипт, сгенерированный schema compare.
Расскажите плиз о других способах генерации скрипта, отличных от schema compare.
S>Для комфортной работы придётся: S>1. Обновиться до GDR R2. По возможности переходить на 2010ю студию, в VSTSDB 2008 множество багофич без шансов на исправление.
Улучшения 2010 студии не перекрываются её сыростью? А то мы пока решили дождаться SP1.
Кстати, о багофичах:
— Сейчас VSTSDB 2008 с GDR R2 выдаёт ворнинги (unresolved reference to object), если в хранимке используется временная таблица (вида #table). Примечательно, что в Management Studio для R2 такие временные таблицы начали распознаваться Intellisence.
— Не смог сделать импорт базы из SQL Server 2008 Express R2. Как оказалось 2008R2 не поддерживается, нужно юзать 2010 студию.
S>6. Сразу же озаботиться общим стилем кода — либо приобретать что-то платное (ходят слухи что кактолькотаксразу выпустят бесплатный автоформаттер), либо писать свои правила для static code analysis. Энфорсить стоит: S>- обязательные точки с запятой
Расскажите поподробнее, какие могут быть проблемы S>- N перед nvarchar-строками S>- запрет на deprecated-фичи S>- псевдонимы для таблиц
С остальным полностью согласен
Большое спасибо, узнал много ценной информации.
Таким образом, сейчас я получил такую картину организации работы:
1. Пара разработчиков работают над проектом БД (каждый над своей веткой), деплоят в одну разработчискую базу.
2. Когда работы завершены и все изменения смёржены, один из разработчиков с помощью Schema compare (проекта и схемы рабочей базы) генерирует скрипт со всеми изменениями. Тщательно просматривает его и деплоит на рабочую базу.
Здравствуйте, Poul_Ko, Вы писали:
S>>1. Обязательно иметь тестовый сервак, на него деплоить только пересозданием базы. В результате имеете постоянно рабочий deployment script для новых инсталляций. P_K>Разве из проекта нельзя создать скрипт для новой инсталляции? Или у этого тестового сервера иная цель?
Да. Смысл в том, чтобы быть уверенным в работоспособности решения. Часть ошибок возникает только при чистом деплойменте, у меня так с месяц гулял странный баг. Почему студия (тогда 2008я) молчала при обновлении таргет-базы — .
P_K>Расскажите плиз о других способах генерации скрипта, отличных от schema compare.
Основных способов два: либо schema compare, либо deployment script — для юз-кейза с автоматическим обновлением существующей базы мне надо самому освежить матчасть, чуть попожже отпишусь.
P_K>Улучшения 2010 студии не перекрываются её сыростью? А то мы пока решили дождаться SP1.
Нет. Я явных багов в самой VS не заметил. Вот в extensions их дофига.
P_K>- Сейчас VSTSDB 2008 с GDR R2 выдаёт ворнинги (unresolved reference to object), если в хранимке используется временная таблица (вида #table). Примечательно, что в Management Studio для R2 такие временные таблицы начали распознаваться Intellisence.
Сам не сталкивался, но что-то такое на официальном форуме обсуждалось. У нас временные таблицы (как и курсоры) не используются вообще, даже довольно сложные алгоритмы типа разграничения доступа как-то удаётся сделать чистым sql'ем. Вот табличные переменные где-то были...
P_K>Как оказалось 2008R2 не поддерживается, нужно юзать 2010 студию.
Да.
S>>- обязательные точки с запятой P_K>Расскажите поподробнее, какие могут быть проблемы Features Not Supported in a Future Version of SQL Server (остальные deprecated также не стоит использовать):
Transact-SQL
Not ending Transact-SQL statements with a semicolon.
Кроме этого, из мелких доводов: явная декларация намерений, тот же with требует перед собой точку с запятой,
P_K>1. Пара разработчиков работают над проектом БД (каждый над своей веткой), деплоят в одну разработчискую базу.
Да, цепочка такая: update-fix-deploy-fix-deploy-...-commit
*fix — правим возникшие багоглюки.
Если у вас при деплойменте на тестовый сервер выполняются тесты — ещё лучше.
P_K>2. Когда работы завершены и все изменения смёржены, один из разработчиков с помощью Schema compare (проекта и схемы рабочей базы) генерирует скрипт со всеми изменениями. Тщательно просматривает его и деплоит на рабочую базу.
Да. Первые проверки можно сделать в самой Schema compare — копаем её настройки.
Особый гемморой при деплойменте — sqlcmd variables. В 2008 студии Schema Compare может нагенерить скрипт, полный $(var).
Re[3]: Организация работы над MS SQL 2008 DB Project
Здравствуйте, Poul_Ko, Вы писали:
P_K>Расскажите плиз о других способах генерации скрипта, отличных от schema compare.
для юз-кейза с автоматическим обновлением существующей базы мне надо самому освежить матчасть, чуть попожже отпишусь.
К сожалению память не подвела: нормальной документации нет. Всё, что советует MSDN — включить "Block incremental deployment if data loss might occur" и предварительный бэкап, выключить пересоздание базы и разбираться в каждом отдельном случае
Поработал над проектом БД в студии, хочу поделиться впечатлениями, вдруг кому будет полезно.
P_K>1. Пара разработчиков работают над проектом БД (каждый над своей веткой), деплоят в одну разработческую базу.
С деплоем в одну базу оказалось не всё так просто — необходимо просматривать генерируемый студией deployment-скрипт, иначе есть риск убить изменения, сделанные другим разработчиком. Т.е. автоматический деплой отменяется.
Думаю, если разработчики будут друг другу сильно мешать, то можно выделить каждому отдельную базу, плюс одну общую для проверки суммарных изменений. У нас пока конфликтов изменений минимум и решается всё организационно.
P_K>2. Когда работы завершены и все изменения смёржены, один из разработчиков с помощью Schema compare (проекта и схемы рабочей базы) генерирует скрипт со всеми изменениями. Тщательно просматривает его и деплоит на рабочую базу.
Напомню, одним из обстоятельств является то, что доступ к серверу с рабочей базой только по терминалу, поэтому изначально планировалось готовить deployment-скрипт локально, используя .dbschema файл со структурой рабочей базы.
Однако и тут облом: Schema Compare в студии не умеет генерировать скрипт, если проект сравнивается с файлом .dbschema.
Поэтому порядок действий пришлось изменить:
1. билдим проект локально, в папке sql\debug (или release) появляется файл с расширением .dbschema
2. копируем этот файл на сервер с рабочей базой
3. на сервер с рабочей базой предварительно скопирована утилита vsdbcmd, натравливаем её на файл .dbschema и на рабочую базу, в результате получаем sql-скрипт. Здесь главное правильно настроить параметры, иначе скрипт будет очень большой с кучей ненужностей
4. просматриваем и правим скрипт, запускаем.
.