Это то место, где маркетинговый отдел Microsoft вышел из-под контроля. Важно понимать, что Microsoft не является компанией, которая пишет код. Microsoft - маркетинговая компания, которая пишет код.
Ответ прост: SSDT - это пакет шаблонов проектов для бизнес-аналитики.
SSDT содержит три типа шаблонов:
- SSIS: службы интеграции
- SSRS: службы отчетности
- SSAS: службы анализа
UPDATE
Я не смог ответить на вопрос о запуске пакетов. По сути, вы можете запустить любой пакет SSDT для SQL Server в Visual Studio. Однако, если вы хотите развернуть пакеты SSDT на SQL Server, у вас должны быть установлены эти службы. Службы можно установить с помощью мастера установки экземпляра SQL Server. Вам необходимо помнить о другой концепции, известной как таргетинг версий SQL Server: Нажмите здесь
Например, если вы хотите развернуть и запустить пакеты служб SSIS на SQL Server, вам потребуется установить службы интеграции (в том числе DTExec.exe и ISDeploymentWizard.exe). Теперь вам также необходимо установить SSISDB на SQL Server, чтобы иметь возможность развертывать пакеты SSIS на SQL Server - это выполняется через SQL Server Management Studio (SSMS). Фактические пакеты развертываются и управляются из папки с именем Каталог служб Integration Services . Затем пакеты могут быть автоматически запланированы для запуска через агент SQL Server. Крайне маловероятно, что вы когда-либо будете работать напрямую с SSIDB, за исключением, возможно, запроса его информации: см. Здесь .
См. Инструкции Microsoft: нажмите здесь
Пакеты SSRS управляются через отдельный веб-интерфейс, и я не работал с пакетами SSAS. Разве это не весело?
Примечание по DTExec.exe
Я столкнулся с пуристами, которые презирают SSIS, в основном потому, что они этого не понимают. Общий аргумент, который я получаю, заключается в том, что он медленнее, чем PowerShell или хранимые процедуры. Это может привести к взрыву чьей-то головы.
По сути, PowerShell запускается через .NET Framework, который находится в C #, и для выполнения должен проходить через несколько уровней в ОС. В то время как компоненты служб SSIS написаны на C #, приложение DTExec.exe написано на C ++, которое может напрямую обращаться к системным ресурсам (C # не может сделать это, потому что это управляемый код!). Итак, SSIS собирается взорвать PowerShell и хранимые процедуры в больших задачах.
Хранимые процедуры - это другое животное, но они все еще медленнее, потому что в них отсутствует буфер конвейера (т. Е. Вкладка «Поток данных»). Другое важное ограничение - это то, как SQL Server выполняет хранимые процедуры, и это последовательно. Итак, давайте представим, что сопоставимое задание SSIS разбито на несколько хранимых процедур и что эти процедуры вызываются основной хранимой процедурой - так сказать, супер хранимой процедурой. SQL Server будет выполнять хранимые процедуры последовательно, по одной за раз - это огромное узкое место в производительности. Конвейерный буфер SSIS стирает это, обрабатывая по умолчанию 10000 строк (это настраивается, кстати) в каждой задаче, а затем передавая их следующей задаче. Таким образом, мы можем думать о задачах потока данных как о своей собственной хранимой процедуре.
Дополнительный контекст
Существует давняя путаница с тем, что представляет собой SSIS в том смысле, как он относится к Visual Studio , не обязательно к SQL Server.
- До 2005 года: это были службы преобразования данных ( DTS )
- 2005 и 2008: В 2005 году DTS был существенно переработан и переименован в SSIS в конце разработки. Вот почему все в SSIS все еще ссылается на DTS (т.е. файлы * .dtsx). Это остается делом по сей день. Странно, только мазохист любит DTS. НО! Пакет шаблонов был переименован в Business Intelligence Development Studio ( BIDS )
- 2012 и 2013: он был переименован в SSDT-BI . По-видимому, уже был другой продукт под названием SSDT
- 2015 и вперед: теперь он называется SSDT
См. Попытку Microsoft объяснить SSDT: нажмите здесь
Вплоть до Visual Studio 2017 (VS 2017) SSDT и его различные воплощения в значительной степени рассматривались как идиотский шаг по отношению к Visual Studio. Я говорю это потому, что VS был установлен как самостоятельный продукт только для этих типов проектов. Я не знаю, почему это было сделано именно так - я думаю, что SSDT бесплатен. В любом случае, если вы хотите использовать Visual Studio для разработки других приложений, вам нужно было установить отдельный экземпляр Visual Studio. Итак, у нас, разработчиков, буквально две автономные установки на нашем устройстве dev, и мы должны использовать конкретную установку для всего, что мы делаем (то есть для разработки с SSDT или без SSDT).
Теперь, с VS 2019, Microsoft покончила с этой моделью и наконец интегрировала пакет SSDT в продукт. Впрочем, первоначальное развертывание VS 2019 для SSDT было комедией ошибок прямо из коробки. Смотрите мое объяснение, нажав , нажав здесь . По существу, SSIS не устанавливается вместе с пакетом и должен добавляться отдельно. Хотя у вас все еще есть один экземпляр VS 2019. Кроме того, поставщик данных SQL11 устарел. И это, по-видимому, тоже не входит в пакет установки и должен быть установлен отдельно. Таким образом, любые существующие пакеты, которые его используют, должны быть обновлены и повторно развернуты (см. Известная проблема № 1).
Пока что я не могу перейти на VS 2019. VS 2017 был боль по меньшей мере. Лично я все еще использую VS 2013 Update 5. Все экземпляры VS ориентированы на SQL Server 2014.