invmТ.е. об этих дополнительных накладных расходах вы решили скромно умолчать?
Что значит - дополнительных? Join СУБД никаких расходов не несет (не сортирует для merge, не создает хеш для hash)?
invmДа? И как же она их блокирует так, что они остаются монопольно заблокированными на время транзакции? И, главное, зачем?
Вы очевидно приписали мне слово "монопольно". Вам так важен данный спор?

Успокойтесь и представьте себе две ситуации. В первом случае соединяется десяток таблиц, чтобы вставить результат в одиннадцатую. Во втором случае - все операции чтения и записи независимы. Для простоты все чтения в обоих ситуациях фуллскан. Вопрос: есть ли разница в потреблении ресурсов СУБД?
invmИ что такое ресурсы для преобразования данных?
Это выделение памяти, ядер, запись в лог, обновление статистики выполнения. Я говорю об этом максимально обще, как о том, что не расходуется SSISом или расходуется, но принципиально иначе - за счет чего можно выиграть.
invmИ чтоб эти ресурсы не блокировались нужно добавить отдельный сервер для ETL со своими ресурсами?
Вы совершенно правы.

КесарьТогда я не понял, в чём проблема.
Я не dermama, у меня нет проблемы с решением. У меня есть непонимание с человеком, притворяющимся неразумным. Но даже это не является проблемой.
КесарьБизнес-логика легко реализуется на sql любая, которая может быть представлена в виде транзакций (у вас ведь не управление атомной станцией?). Банковские операции заведомо реализуемы в sql. По определению.

Задержки относятся не к бизнес-логике, а к архитектуре, качеству кода, качеству работы команды админов и наконец просто напросто к мощности железа.
Ну хорошо, приведу конкретный пример. В таблице области Stage лежит, скажем, десять тысяч записей. Нужно "смержить" ее с соответствующей таблицей в детальной области, содержащей полмиллиарда записей, в течение 1 минуты. Спустя еще одну минуту - повторить. При этом минимально влияя (конкурируя за ресурсы) с аналитическими запросами к детальным данным. Жду предложений, как это сделать на SQL, причем на скромном виртуальном сервере.
invmТо и значит. У сервера три стратегии соединения, у SSIS - одна
И это значит, что у вас три инструмента, у меня - четыре. Понимаете разницу? Или снова прикинетесь?
Также в SSIS есть кешируемый лукап - это пятый инструмент, когда не ожидается размножение строк.
Наконец, в SSIS есть Script Task с возможностями C# - это шестой инструмент.
Конечно, в MS SQL есть CLR - но кому придет в голову использовать его для соединений?
invmКонечно приписал. Ибо без "монопольно" ваше объяснение про заблокированные "таблицы-источники" не имеет смысла.
Конечно, приписывать собеседнику свои слова в цивилизованном разговоре не стоит. Вместо этого лучше использовать вопрос: "Правильно ли я понял, что...?" и объяснить свои сомнения. Например, правильно ли я понял, что блокировки S вы блокировками не считаете?

Когда вы просто читаете таблицу-источник, то блокируете S текущую читаемую страницу, освобождая сразу по окончании чтения.
Когда вы используете таблицу-источник внутри оператора модификации данных, то блокируете с учетом эскалации S всю таблицу (прочитанные данные) и освобождаете по окончании транзакции.
С этим вы согласны или нет?
invmНу так объясните нам, неразумным
Извините, но я специально просил вас "не притворяться глупее, чем мы есть". Почему вы считаете нормальным игнорировать мою просьбу и одновременно ожидать ответа на свою? Если вы неразумный, то какой смысл тратить на вас время?
invmВы, видимо, работаете у какого-то вендора ПО.
Ибо только там считают, что клиенту дешевле купить пару-тройку новых серверов со всеми необходимыми лицензиями на софт, чем нарастить ресурсы на одном сервере.
А вам сама архитектура с выделенным сервером не кажется избыточной в сравнении с файл-серверной? Access намного дешевле MS SQL, а SQLite и вовсе бесплатен.
В моем случае две скромных виртуалки, специализированные по нагрузке, обходятся дешевле и работают эффективнее, чем один универсальный сервер. Да и надежнее.

invmНе надо уводить дискуссию в сторону. Речь идет о ваших утверждениях о преимуществе join на стороне SSIS. Итого 1.5 стратегии соединения на сторогне SSIS и 3 на стороне сервера.
Второй раз. Я сказал, что join снаружи может быть быстрее, чем join внутри. Не обязан быть быстрее всегда, а может . Используя ETL, я могу осознанно передавать ему эти случаи.
invmНе учите меня жить - это не в вашей компетенции.
Приятно повеяло годами моей молодости, а именно лозунгом "Не учите меня жить, лучше помогите материально".
Вот мне не зазорно учиться даже у неразумных людей: я приму ваши слова о блокировках к сведению и разберусь, почему у меня сложилось мнение, о котором я написал выше. Не прямо сейчас, но позже.
Если же вам кажется, будто я пытаюсь вас чему-то учить, то вы ошибаетесь. Я просто поступаю в своем стиле и объясняю, почему. Заставлять вас следовать моему примеру не стану, ибо по большому счету пофиг. Да и, как говорится, можно подвести лошадь к воде, но нельзя заставить ее пить.

Впрочем, не беря в расчет конкретно блокировки и возвращаясь к преимуществам ETL, любой запрос с модификацией все равно пишет в лог, выделяет память и потоки под обработку данных - то, что SSIS не делает или делает, но совсем иначе.
invmНе сравнивайте теплое с мягким. Впаривание дополнительных серверов клиенту для решения задач, которые спокойно можно решать без оных - просто развод клиента на деньги.
Ваше убеждение в том, что выделенные серверы (только ETL? какие-то еще?) не нужны, вы никак не обосновываете. Я привел пример задачи, которая, по словам другого участника темы, требует дополнительного сервера. Только одной задачи среди многих выполняемых. Видимо, вы этого замечать не желаете.

invm не нравится сервер ETL, alexeyvg не нравится шина... Надеюсь, я не столь агрессивен и категоричен в отношении хадупа.
КесарьЕсли вы хотите, чтобы вас тут похвалили и оценили, то вы - безусловно молодец.
Когда я действительно захочу, чтобы меня оценили именно на форуме, я напишу доклад или презентацию. Пока мне достаточно оценки со стороны руководства. Хотя можно обкатать тезисы, типа "ETL имеет право на жизнь"...

invmНу вот и продемонстрируйте каким образом и засчет чего это "может" происходит. Пока что от вас только бла-бла-бла.
Т.е. вы требуете демо-пример, и ради вашего убеждения я должен развернуть тестовую среду, подготовить опытные примеры и собрать по ним статистику выполнения.
Ок, могу. Но не бесплатно. Вы готовы оплатить мой труд?
invm.ЕвгенийВпрочем, не беря в расчет конкретно блокировки и возвращаясь к преимуществам ETL, любой запрос с модификацией все равно пишет в лог, выделяет память и потоки под обработку данных - то, что SSIS не делает или делает, но совсем иначе.Еще раз - не уходите в сторону. Обсуждается join на стороне SSIS, а не преимущества ETL.
Вы не понимаете, что именно об этом я и говорил - о том, что SSIS при выполнении join не делает или делает, но совсем иначе, в сравнении с MS SQL.
invmВыделение под какую-то задачу отдельного сервера требует обоснования. Утверждение типа "я знаю как это сделать на SSIS на выделенном сервере, но не знаю как тоже самое равноэффективно реализовать на сервере БД" таковым не является.
Во-первых, реализовывать задачи на сервере БД не является самоцелью. Невыделение отдельных серверов - тоже не самоцель.
Во-вторых, отсутствие способа это частный случай незнания способа. Когда выбирается способ решения более-менее сложной задачи, то человек с опытом и без избытка тщеславия не заявит безусловную невозможность решения задачи некими средствами (в данном случае сервером БД). Он скажет: "Если такой способ и существует, то я его не знаю". И предложит свой вариант решения.
В-третьих, а знаком ли вам вкус устриц, чтобы обсуждать его в столь самоуверенной форме с теми, кто их уже ел? Приходилось ли вам работать со средствами ETL в целом и SSIS в частности и насколько глубоко?

alexeyvgЕсли нужно получить связанные с другим множеством данные, то первый вариант исключаем - join сделать надо.

По пункту "иначе", хотелось бы подробностей - какие секретные технологии скоростного join-а используются в SSIS, и почему разработчики не поделились ими с разработчиками Database Engine?
Прошу вас, читайте мои предыдущие сообщения. Повторяю свою фразу:
"У SSIS намного меньшие издержки, ему не нужно поддерживать транзакционность, лог, статистику выполнения и т.п."
alexeyvgА вы уверены, что знакомы, поэтому считаете правильным использовать в беседе настолько самоуверенные формы?
Я стараюсь избегать самоуверенности, если у меня не получилось - укажите, где это произошло.
Я не требую делать те или иные задачи на SSIS или строго доказать мне нежелательность его применения.
Но когда заявляют некую невозможность, а у меня есть противоположный опыт, то я могу им поделиться.
Если кого-то мой опыт возмущает - это его проблемы.