Comments 25
На БД какого размера вы тестировали работоспособность этого подхода? Как себя поведет инструментарий, когда вам надо одновременно (и синхронно) поддерживать 20+ БД?
Признаюсь, наша база не отличается слишком большим количеством объектов и объёмом данных (проект только начался). Но я не вижу причин, по которым этот подход может не сработать, если размер базы увеличится. Касательно поддержки «20+» — инструмент не даёт ни чего специального. В вашем случае я бы создал solution с отдельными Database проектами. Это позволит получить отдельный DACPAC для каждой базы и поставлять изменения по необходимости в каждую базу отдельно.
Но я не вижу причин, по которым этот подход может не сработать, если размер базы увеличится.
Рефакторинг и построение изменений по десяткам тысяч объектов?
Это позволит получить отдельный DACPAC для каждой базы и поставлять изменения по необходимости в каждую базу отдельно.
А как же согласованные изменения? А отслеживание зависимостей между БД?
Рефакторинг и построение изменений по десяткам тысяч объектов?
Наверняка на такой базе процесс переименования будет проходить дольше, чем на нашей. Но всё равно он будет выполнен успешно и за умеренное время. Конретных цифр не могу привести, но склонен верить, что это будет не медленней, чем при использовании аналогичных иструментов (например SQL Bundle от Red Gate). Вообще на таких размерах думаю без использования чего-то подобного просто невозможно вести разработку и эти инструменты — MUST HAVE.
А как же согласованные изменения? А отслеживание зависимостей между БД?
Если вы используюте механизмы Linked Server или его аналоги (OPENDATASOURCE и OPENROWSET) и в хранимках или вьюхах одной базы на прямую задействованы объекты других баз (таблицы, вьюхи, хранимки), то конечено автоматически рефакторинг это не исправит. Но с другой стороны, если у вас действительно всё так организовано и часто меняются таблицы, от которых зависят внешние базы данных, то тут уже проблема подхода. Как по мне, не стоит напрямую использовать эти объекты из внешних баз, если они могут меняться.
В свою очередь, будет интересно узнать, как вы сейчас боретесь с этими проблемами и есть ли какой альтернативный подход?
Но всё равно он будет выполнен успешно и за умеренное время.
Умеренное — это сколько? Час, два, десять?
Вообще на таких размерах думаю без использования чего-то подобного просто невозможно вести разработку и это просто MUST HAVE.
«Невозможно» — это «мы пробовали, и у нас не получилось», или «мы даже не пробовали»?
Как по мне, не стоит напрямую использовать эти объекты из внешних баз, если они могут меняться.
И как же с ними работать тогда?
В свою очередь, будет интересно узнать, как вы сейчас боретесь с этими проблемами и есть ли какой альтернативный подход?
Мы с ними боремся тестами.
Умеренное — это сколько? Час, два, десять?
Я уже писал что конкретных цифр не могу привести, но внутри одной базы рискну предположить что это будут секунды или десятки секунд, но ни как не часы. Всё-таки Resharper делает похожие вещи в C# коде и у меня был опыт работы с проектами, в которых были десятки тысяч файлов.
«Невозможно» — это «мы пробовали, и у нас не получилось», или «мы даже не пробовали»?
Скорее пробывали и было крайне не удобно. Тесты могут спасти и показать где проблема, но я предпочту сделать все необходимые изменения и запуская тесты, просто убеждаться, что я ничего не поломал, вместо того, что бы видеть, где нужно починить.
И как же с ними работать тогда?
Затрудняюсь дать ответ конкретно по вашему случаю, т.к. для этого явно мало информации по вашему проету. Но наверняка можно, если не полностью убрать последствия переименования, то хотя бы свести их к минимуму. Возможно помогут механизмы репликации. Возможно пересмотр подходов к выборке: вместо SELECT'а из внешней базы можно вызывать во внешней базе хранимку и получить уже готовый результат. При этом подходе хранимка будет храниться в той же базе где и сама таблица и рефакторинг можно будет сделать при помощи предложенного инструмента (кроме конечно случая, когда сама эта хранимка переименовывается). Но в общем, нужно смотреть каджый проект в отдельности и давать советы только после близкого знакомства с ним.
Мы с ними боремся тестами.
SSDT не отменяют и не запрещают использование тестов. Наоборот, они упрощают их создание, чем в свою очередь способсвуют повышению степени покрытия тестами (легче тестить — можно за то же время больше покрыть). Об этот есть отдельный раздел в статье.
PS: я не претендую на то, что SSDT должны заместить все имеющиеся наработанные практики и быть панацеей для всего. Я просто хочу сказать, что они могут упросить или решить ряд ежедневных проблем, которые без подобного иструмента решаются гораздо сложнее.
Всё-таки Resharper делает похожие вещи в C# коде и у меня был опыт работы с проектами, в которых были десятки тысяч файлов.
У Решарпера очень неслабый механизм анализа и кэширования его результатов. И все равно при включенном изменении строковых ссылок он ощутимо задумывается даже на тысячах файлов.
Скорее пробывали и было крайне не удобно.
На БД какого размера?
я предпочту сделать все необходимые изменения и запуская тесты, просто убеждаться, что я ничего не поломал, вместо того, что бы видеть, где нужно починить.
Я тоже предпочту. Но я не знаю ни одного инструмента, который это может в описанных условиях.
Возможно пересмотр подходов к выборке: вместо SELECT'а из внешней базы можно вызывать во внешней базе хранимку и получить уже готовый результат. При этом подходе хранимка будет храниться в той же базе где и сама таблица и рефакторинг можно будет сделать при помощи предложенного инструмента (кроме конечно случая, когда сама эта хранимка переименовывается).
А если меняется структура отдаваемых хранимкой данных или принимаемые ей параметры?
Я просто хочу сказать, что они могут упросить или решить ряд ежедневных проблем, которые без подобного иструмента решаются гораздо сложнее.
Вопрос в том, какой оверхед SSDT добавляют в проект, и в какой момент этот оверхед становится больше, чем приносимая польза. Вернемся к простому примеру: вот у вас есть несколько БД, в которые нужно внести согласованные изменения. Как это сделать с помощью SSDT?
Уважаемый, lair. Как я уже сказал, я не ставлю за цель убедить вас и ваших коллег в том, что бы вы пришли к использованияю SSDT. Каждый волен принимать решение по своему усмотрению. Если вы искренне верите, что SSDT вам будет больше мешать, чем помогать, то я не стану доказывать обратное. Наш с вами диалог понемногу начинает мне напоминать известную картинку, поэтому с Вашего позволения, я не буду продолжать это обсуждение и оставлю за собой право верить, что всё-таки найдутся читатели хабра, которым данный иструмент больше поможет, чем помешает и они будут рады узнать о его существовании.
А как вы сейчас вносите согласованные изменения в разные БД на разных серверах?
Я тут подумал, что не знаю эффективного способа, желательно в одной транзакции.
Я тут подумал, что не знаю эффективного способа, желательно в одной транзакции.
Мы используем linked servera в разработке проектов. Зависимости между БД SSDT точно может отслеживать. Решается просто:
Более того, при изменении в одном месте с помощью рефакторинга, SSDT автоматически меняет ссылки во всех связанных базах, так что согласованные изменения также возможны.
Скорость рефакторинга проверить не могу, баз с десятками тысяч объектов нет.
- Добавить в solution все связанные БД.
- Добавить переменную, которая будет ссылаться на linked сервер:
- Аналогично добавить переменную, которая будет ссылаться на БД на этом сервере
- Использовать в скриптах эти переменные:
SELECT dbo.Customers.Id, a.Id, FROM dbo.Customers LEFT OUTER JOIN [$(SrvSql1)].[$(Accounts)].dbo.account AS a ON dbo.Customers.Name = a.Name
- При этом, если колонки a.Id в linked базе не будет, SSDT укажется на ошибку и не даст собрать проект
Более того, при изменении в одном месте с помощью рефакторинга, SSDT автоматически меняет ссылки во всех связанных базах, так что согласованные изменения также возможны.
Скорость рефакторинга проверить не могу, баз с десятками тысяч объектов нет.
Более того, при изменении в одном месте с помощью рефакторинга, SSDT автоматически меняет ссылки во всех связанных базах, так что согласованные изменения также возможны.
Пакет изменений генерится один на все БД?
Для каждого проекта генерится отдельный DACPAC. Так как один проект представляет одну базу, я думаю в решении Dim0FF будут различные пакеты для каждой базы.
Это космос. Щас погонял на боевой базе. Компейр отрабатывает за секунд 20 на моей базе в 3к объектов. Чувствую моя жизнь станет много приятнее. Спасибо за инфу.
Подскажите есть ли настройка или как сделать, чтобы при добавлении/изменении колонки в таблице в миграционных скриптах вместо DROP / CREATE был ALTER TABLE
Перепроверил и не смог получить поведение с DROP/CREATE. Возможно я проверял на другой версии MS SQL Server, но мои результаты следующие: у меня была таблица Table с колонкой LastName; переименовал колонку в Surname и добавил новую колонку NewColumn; в результирующем миграционном скрипте вижу:
Встречные вопросы:
1) На какой версии сервера проверяли Вы?
2) Какие именно вы проверяете скрипты? Ведь то что в проекте это не миграционные скрипты.
3) Вы для переименовки пользовались функцией SQL-> Refactor-> Rename?
--...
EXECUTE sp_rename @objname = N'[dbo].[Table].[LastName]', @newname = N'Surname', @objtype = N'COLUMN';
--...
ALTER TABLE [dbo].[Table]
ADD [NewColumn] INT NULL;
--...
Встречные вопросы:
1) На какой версии сервера проверяли Вы?
2) Какие именно вы проверяете скрипты? Ведь то что в проекте это не миграционные скрипты.
3) Вы для переименовки пользовались функцией SQL-> Refactor-> Rename?
Вы забыли упомянунть про тип проекта Reporting Service. Без этого пакета с ssrs вообще тяжко работать когда отчетов много. Спасибо за инфу в массы.
На самом деле не забыл, а умышленно пропустил. У меня с ним опыта практического очень мало. Для себя смотрел, но толково рассказать бы не смог, поэтому решил не портить статью куском «а бы что нибудь рассказать» и решил оставить это для других, например для Вас. Думаю Вы сможете написать статью, а на мою статью разрешаются сослаться, как на вступительную часть :).
Что касается Reporting Service, Analysis Service, Integration Service (в общем, всё то, что раньше включала в себя BIDS), там всё очень грустно. По крайней мере, на мой взгляд. Со времен SQL Server 2008 в инструментарии не вылечена ни одна детская болячка, и можно сказать, он вообще не изменился за шесть лет, (если не считать такой важной фичи, как поддержка цветовых тем интерфейса).
Вот самые печальные:
В проекте Reporting Service до сих пор нельзя ни шаблоны ролей безопасности настроить, ни путь расположения отчета на сервере указать. Проект Analysis Service до сих пор страдает кошмаром для разработчика — если нехороший админ переименует хоть одну группу в AD, на которую завязаны роли в проекте, опубликовать его не получится. Но никак, ни под какой пыткой SSDT вам не признается, какая группа вызвала проблему, вам придется проверять их все поименно. А в Integration Service хотелось бы просто иметь что-то, хоть отдаленно похожее на вменяемый редактор скриптов, а не дикую мешанину текстовых полей и визуальных элементов.
Вот самые печальные:
В проекте Reporting Service до сих пор нельзя ни шаблоны ролей безопасности настроить, ни путь расположения отчета на сервере указать. Проект Analysis Service до сих пор страдает кошмаром для разработчика — если нехороший админ переименует хоть одну группу в AD, на которую завязаны роли в проекте, опубликовать его не получится. Но никак, ни под какой пыткой SSDT вам не признается, какая группа вызвала проблему, вам придется проверять их все поименно. А в Integration Service хотелось бы просто иметь что-то, хоть отдаленно похожее на вменяемый редактор скриптов, а не дикую мешанину текстовых полей и визуальных элементов.
С публикацией вообще какой-то лютый бред — весь проект можно заопубликовать только в одну единственную папку, я прям этого уже не понимаю. Работа с иерархией файлов на сервере прямо противоречит здравому смыслу. Хотя так на первый взгляд все правильно. Но для каждой папки приходится создавать свой проект, со своими датасорсами, это не правильно на мой взгляд.
Самая классная фича — это scheme compare, сравнить локальную, тестовую или продакшен базу, сгенерировать скрипт или сразу напрямую накатить изменения.
Sign up to leave a comment.
Microsoft SQL Server Data Tools