А статистика именно по компаниям, склонным к использованию .NET или в целом? Потому что у меня эмпирические картины сильно отличаются. Там где fluentd редко наблюдается .NET. Там где .NET наиболее частая связка serilog+filebeat+logstash.
Странно, ни разу не сталкивался с таким мнением. Проектов на .NET было предостаточно. Северная Америка, Южная, Европа, Океания. От мелких бизнесов до транснациональных. В одном только ООН его море. Кто-то из доверия к бренду, кто-то в силу остального ландшафта в компании, кто-то из-за инструментов. WebForms/WPF были особенно в ходу, поскольку Delphi был не так распространён за пределами СНГ, а какой-нибудь MFC давался сильной болью. Огромное количество бизнес-софта, скажем тот же немецкий Sage (что-то в духе нашего 1С).
И почему все считают, что Бейсик тут отстаивается как самодостаточный функциональный современный ЯП?
Я сравнивал BASIC с Pascal. Так что вы ошиблись адресатом.
Бейсик поддерживает и массивы — первый шаг к структурам.
Я бы спросил, а куда делать следующий шаг, поскольку речь шла о массиве кругов. Но уже понятно, что с вами шагать очень долго. У детей темп намного выше))
В некоторых их и не было никогда, в других предпочтение отдавалось рекурсии. А в иных они всё чаще становятся просто синтаксическим сахаром для итераторов. И, наконец-то, вместо этой уродливой императивной конструкции есть нормальный масштабируемый вариант. Хочешь — многопоточность добавляй, хочешь — партиционирование. Не надо обходить весь код и вырезать эти циклы, громко матерясь.
И переменные тоже упразднили из современного программирования?
У вас, как я понимаю, очень дискретное мышление? Попробую пояснить на примере. В ES6+ var остался, но практически все best-practices рекомендуют использовать const. В языках вроде Rust, F# и многих других надо принудительно указывать мутабельность, но она не очень приветствуется. Я это рассматриваю как постепенное движение к иммутабельности. А для вас факт поддержки переменных — это то, что они основы?
В каких-то языках — возможно и будет. Но далеко не во многих :) И поморгать мне на мой век хватит, да и детям моим тоже :)
А там много не надо. Достаточно одного, чтобы большая часть рынка программистов осталась без работы.
И как этот переход в BASIC будет выглядеть? "Доброе утро, котятушки. Вчера я вам показывал рисование круга на BASIC. Но этот язык настолько убогий, кроме строк и чисел ничего не поддерживает, поэтому сегодня начнём изучать новый".
Ассемблером можно заинтересовать. Я в таких случаях использую embedded-платформы, от простых контроллеров, где можно помигать светодиодами, до чего-то роботизированного. Но это другой вектор развития.
Из всего богатого мира software engineering вы взяли только computer science, оттуда выдернули маленький кусочек, касающийся исключительно одной вычислительной модели, с уклоном на наиболее типовые микропроцессорные архитектуры и называете это основами программирования?
Я через десятилетия несу любовь к ассемблеру, что не мешало мне программировать от Рефала или Пролога до SQL, XSLT, выводке всяких ML, Gherkin и т.п., которые с недоумением смотрят на ваши выводы, отрицающие существование символьного, декларативного, мета- и других форм программирования.
Я так понимаю, что для вас Марков или Чёрч — это не основы, а НАМ или лямбда-исчисление недоразумение. Ну тогда я вам могу предложить основу ещё более основательную — машина Тьюринга. Не благодарите, получайте удовольствие. Говорят удачный вариант реализации в языке Brainfuck.
Мы опять говорим про переходы, которые многие из нас осуществляли в прошлом. Современный мир — это совершенно другие приоритеты. Циклы? Вы пропустили тот момент, когда вся индустрия испытывала дикую боль, поскольку циклы не масштабировались на многоядерные системы? Переменные? Вы остались в стороне от страшных пыток многопоточными приложениями и не заметили, что мир становится всё более иммутабельным?)) Всё сейчас заметно движется в сторону обогащения системы типов. Не успеете моргнуть, как вместо условий у вас будут dependent types. И сейчас у многих идёт конкретная ломка, как избавиться от этого старого императивного багажа, который больше не работает. А вы предлагаете продолжать его культивировать.
ну тоесть вы считаете что работа с объектами — это лучший вариант в программировании?
Нет. Я уже не раз написал, что именно я считаю, но видимо вы не читаете.
А вот в реальной жизни практически никогда не нужно оперировать со 'знакомыми объектами'.
С точностью наоборот. В реальной жизни всегда приходиться оперировать со знакомыми объектами. Стейкхолдеры, как и дети, не будут разговаривать с вами на другом языке. А вот уже от привычных для них объектов можно идти в правильном направлении. Вы же считаете, что от системы типов BASIC плясать куда проще. Число, строка… в проекте на Python вам тоже этого хватает?
взять ту-же яву которую многие ява-хейтеры не любят за ад из абстракций и огромные цепочки наследований,
А в Rust отличные абстракции и нет наследования в принципе. Что будем делать с этим фактом?
не попал на проект где объекты и вообще ООП используется только там где это требует фреймворк и базовые примитивы языка, весь бизнес код написан процедурщиной… вот тут я и вспомнил свой древний опыт на доисторическом бейсике
Не хочу принижать этот проект и ваше в нём участие, но объективно я не могу рассматривать это факт. Я тоже попадал в сотни разных проектов. Были и с уродливой кодовой базой, включая процедурщину и мне в голову не придёт этот подход восхвалять. Может это какой-то выдающийся продукт, который кладёт ту же Java на лопатки и можно краем глаза где-то взглянуть? А может как я и предположил, у нас просто разный смысл кроется за аббревиатурой ООП. Я, например, многие практики OOD в SQL использую. Хотя там никакого привычного ООП и в помине нет.
Программы = алгоритмы + структуры данных (с) Никлаус Вирт. Да и алгоритмы — это тоже структуры данных (привет LISP/Scheme и классический курс SICP). BASIC решает только одну часть и решает почень осредственно. Можно учить ребёнка писать Circle(...) как мартышка. А можно научить его описывать структуру Circle, массив таких структур, выводить разным способом (все, чётные, сдвигать, масштабировать, находить самый маленький, большой и т.п.), добавлять новые виды, объяснить обобщение и так постепенно вывести на правильный трек. Желаю удачи с алгоритмами в BASIC. Обучал, знаю.
но это блин не так, он не сильно отличается от других языков
У вас странные критерии сравнения. На мой взгляд он кардинально отличается от других языков. Просто небо и земля. Схожесть только на самом примитивном уровне вроде рудиментарных алгоритмических примитивов. Возьмите любую натуральную задачу. Там где ученики оперирует знакомыми объектами. Пусть даже будет скучный вариант с шахматами. Конструкцию вроде
Figure = class … end;
Board: Array['a'..'h', 1..8] of Figure;
На Pascal я объясню за минуты. А представьте себе описание шахматного мира на BASIC. И попробуйте оттуда хоть что-то перенести в современность кроме нескольких for/if. А потом попробуйте из Pascal.
Когда я говорю о переносимости знаний, я не имею ввиду перенос словаря ключевых слов и примитивных конструкций. Я говорю о переносе опыта и образа мышления.
то что вы говорите про ООП, так не ООП единым же…
Я говорил про типо-ориентированное программирование. ООП только упомянул в примере и это не эквивалентные вещи.
Да и ООП в Си навалом. Если только вы не ограничены одной и далеко не самой лучшей реализацией (трио инкапсуляция+полиморфизм+наследование). Иначе советую немного расширить кругозор, обратиться хотя бы к автору идеи и посмотреть тот же Smalltalk. Вот из него в современность переехать с event-driven архитектурами было бы не в пример проще. Так что ООП — это скорее стиль мышления. Как вы организуете объекты предметной области. Он спокойно может выражаться в конвенции именования ваших функции и ограничиться использованием простых записей. Возьмем что-то из классики, например Postgres:
Если потом посмотреть на имплементации в том же Rust, то будет складываться стойкое ощущение дежа вю. Из такого "не ООП" вы легко можете переехать в тип BloomFilter с методом ContainsValue. И обратно.
Приведите пример индекса без сортировки? Понятно, что реализация процесса в СУБД нагружена спецификой вроде page split, fill factor и т.п., но по сути — это сортировка. Откройте исходники того же Postgres и посмотрите, скажем, как делается ребилд.
А про разницу в плане количества дисковых операций я уже сказал. Планировщик запроса лучше вас решит, будет он использовать индекс или нет. Если у вас в базе пока только десять записей, он не станет делать лишние IO и тащить страницы с индексами. А если у вас их биллионы, то возможно вы уже давно переехали на колумнар и индекса вообще нет, а сортировка есть. В одном случае это B-tree, в другом — BRIN. Вы просто пытаетесь заменить абстракцию (СУБД сортирует и может сделать это множеством способов, включая использование имеющегося индекса), отдельно взятой реализацией. Это не верно, хотя бы согласно принципу DIP.
Зависит от преподавателя. На самом деле рекурсия даже более натуральна. Просто надо ребёнку не на факториале демонстрировать или числах Фибоначчи, а на простой операции подсчёта предметов в мешке.
У нас путь похожий, но выводы разные. Да я писал на BASIC ещё для ДВК-1, да потом без труда перешёл на Pascal (только писал на нём как на BASIC, потратив немало времени на выкорчёвывание стереотипов). После чего переход на C#/Java (я опять же говорю о качественном переходе) дался намного легче. Но мне и в голову не приходит мысль пытаться перенести эту пропахшую нафталином ностальгию в сегодняшний день. Или советовать кому-то повторять этот путь длиной в несколько десятилетий с постоянным ломанием парадигм, выбрасыванием в помойку старых наработок и т.п.
Время примитивного императивного мышления в духе for/if уходит. Когда сегодняшний ребёнок выйдет на рынок труда, там уже вовсю будет типо-ориентированное программирование, что-то в духе Haskell, Idris, Agda и т.п. И мой опыт подсказывает, что для детей оно даже более натурально. Структурирование игровых персонажей, исследование их поведения с применением того же ООП заходит лучше, чем скучные синтетические числовые/символьные задачи, на которых строится BASIC, из-за его убогой системы типов и модульности. Таких детей можно хоть завтра бросать на реальные бизнес-задачи. Может у вас другой опыт преподавания, поделитесь, будет очень интересно.
Что я могу перенести из него в сегодняшний день? Скажите мне. Я тогда вычту его из "всего" и мы получим ответ на интересующий вас вопрос "что надо забыть". И я надеюсь, мы говорим о навыках решения задач, которые формируются в наших нейросетях годами, а не схожести синтаксиса for или if. Вы реально считаете, что некоторый условный тинейджер, начавший с BASIC ничуть не проиграет другим, которые начали с Pascal или Smalltalk?
И как, сильно пригодилось? Я тоже прошёл весь этот путь, но мне и в страшном сне не придёт в голову учить своих… да даже чужих детей BASIC. Я преподавал, начиная от пятиклашек и выше. BASIC — тот случай, когда ты через некоторое время вынужден сказать "А теперь забудьте всё, что мы учили". Если автору так нужно что-то лаконичное и шустрое, то Turbo Pascal просто на голову выше.
Индекс это и есть сортировка. Планировщик запросов сам разрулит, будет ли он использовать готовый индекс, или отсортирует сам. Как говорит документация того же Postgres: "The required sorting might be achieved either by an explicit sort step, or by scanning the relation in the proper order using an index on the join key".
Что именно в случае dtexec мне надо было разжевать? Какие кнопочки в визарде SSMS нажимать, чтобы получить dtsx, дублировать сюда рекомендации по настройке? А код для запуска я вам дал, в своём же бенче dtexec. Плюс дал код для эксперимента с SqlBulkCopy, который давал лучшие результаты. Но с ним вы не справились. Ведь есть риск, что не получится испортить настолько, чтобы тайминг оказался хуже вашего god-варианта.
Тестовый стенд — это тот, на котором вы проводили свои тесты. Поскольку они у вас вообще не соответствуют правилам хорошего бенчмаркинга, оставалось следовать хотя бы одному правилу — тестировать всё в одинаковых условиях. Вы начали эти тесты и логичней сравнивать другие варианты запуская в вашей же среде. Тем более, я то уже тесты провел и на более медленном сетапе скорости намного выше.
Достаточно, спасибо. Даже поверхностный просмотр говорит, что зачем-то вместо SqlNative драйвера вы стали использовать OLEDB, соединение с Postgres вообще за DNS не видно, bcp вы настраивали и сделали батч на 10М записей и сравниваете с dtexec у которого по дефолту батч в 1000 раз меньше, буфер стоит 3М, MaxConcurrentExecutables/EngineThreads не использовались от слова вообще, запускали как я понимаю на Windows. Предвосхищаю, что сейчас начнётся демагогия, мол я должен был все настройки для вашей задачи и вашей же тестовой среды подготовить. Ведь это я претендую на статью, которая громогласно заявляет о том, что нашёл самое быстрое решение. И сразу с этим соглашусь. Да, кто-то должен провести нормальные тесты.
Я перешёл по ссылке в почте, которая отправляет сразу на комментарий. В тексте оного не было никакого намека на то, что статья обновлена. Да и обновлена она в худших традициях хабра. Здесь принято делать update-секции, а не фальсифицировать исходный текст. Мимо. Но можем свалить вину и на меня, я не против, по формальным признакам вы со всех сторон молодец.
"Длительные теоретичесие рассуждения"? Первое, что я сделал — провел тесты со своей стороны и опубликовал полученные тайминги как по dtexec, так по SqlBulkCopy. С учётом нормализации последний был быстрее вашего решения, первый — чуть медленнее, но я его вообще не настраивал. Что мне SSMS сгенерировал, то и воткнул, чтобы сформировать общую оценку. Мимо.
А вот в ответа на бенчи с мой стороны у вас полыхнуло и понеслись "длительные теоретические рассуждения". Мой самый-самый первый комментарий вам содержал удивление, что вы "не пробовали запустить dtexec CLI" и почти каждое сообщение пропитано идеей, что проще протестировать, чем болтать языком. Разжевал всё о dtexec. Что это, где лежит, как использовать. В итоге после длительного треда c вашей теоретической демагогией удалось таки прижать к стенке, но тут вы "мастерски" выкрутились… Мол герой что запустили, назло этому троллю-теоретизатору. Молодец))
На хабре ещё теплилась идея конструктивной дискуссии. И я подумал, что сообща разберёмся, почему в вашем случае SSIS работает намного медленнее чем у меня, может ли быть SqlBulkCopy и какие-то ещё способы быстрее и т.п. Но с вами это не получилось, так что да, смысла в дальнейшей полемике не вижу.
Поэтому бенчи я оформлю нормально и отдельной статьей. Мне как раз скоро надо несколько терабайт скоро перегнать, правда в обратном направлении и акцент на columnar, но затрону оба направления, в том числе попробую и ваш подход. Без иронии вам за него спасибо. У меня в голове он уже пробудил план набросать утилиту, которая будет использовать SqlBulkCopy, но в абстракцию IDataReader будет завернут пайп от постгреса, напрямую, без FS-посредников. А также попробовать какой-нибудь PL-язык, скажем Pl/Python + SQLAlchemy. Дата-саентисты часто вставляют гигантские DataFrame в самые разные СУБД, наверняка что-то должно быть.
Вы либо не понимаете термина "троллинг", либо просто у вас подгорело от того, что плохо разбираетесь в технической стороне вопроса. Скатиться до того, чтобы называть троллингом сугубо техническую информацию, когда я вам разжевал в деталях как оно работает? Даже если бы выяснилось, что я плохо себя представляю плачевность ситуации с ODBC-драйвером, скатываться в технической дискуссии до такого… Да вы, сударь, свинья.
Выложите где-нибудь dtsx, вывод dtexec и настройки postgres. Доверия вашим тестам — ноль. Я перепроверю.
Я как раз постил реальный код и замеры, так что с "теоретическими умозаключениями" мимо.
Вам несколько человек предложили попробовать SSIS, тем более у вас тестовый стенд под рукой. Делов было на несколько минут. Но вместо простой манипуляции развелили демагогию с последующим подгоранием про троллинг.
Мда, результат бенчмаркинга, как и всё у вас, просто выше всяких похвал. Что меряли, как меряли. Видимо, придётся самому нормально делать.
А статистика именно по компаниям, склонным к использованию .NET или в целом? Потому что у меня эмпирические картины сильно отличаются. Там где fluentd редко наблюдается .NET. Там где .NET наиболее частая связка serilog+filebeat+logstash.
Странно, ни разу не сталкивался с таким мнением. Проектов на .NET было предостаточно. Северная Америка, Южная, Европа, Океания. От мелких бизнесов до транснациональных. В одном только ООН его море. Кто-то из доверия к бренду, кто-то в силу остального ландшафта в компании, кто-то из-за инструментов. WebForms/WPF были особенно в ходу, поскольку Delphi был не так распространён за пределами СНГ, а какой-нибудь MFC давался сильной болью. Огромное количество бизнес-софта, скажем тот же немецкий Sage (что-то в духе нашего 1С).
Я сравнивал BASIC с Pascal. Так что вы ошиблись адресатом.
Я бы спросил, а куда делать следующий шаг, поскольку речь шла о массиве кругов. Но уже понятно, что с вами шагать очень долго. У детей темп намного выше))
В некоторых их и не было никогда, в других предпочтение отдавалось рекурсии. А в иных они всё чаще становятся просто синтаксическим сахаром для итераторов. И, наконец-то, вместо этой уродливой императивной конструкции есть нормальный масштабируемый вариант. Хочешь — многопоточность добавляй, хочешь — партиционирование. Не надо обходить весь код и вырезать эти циклы, громко матерясь.
У вас, как я понимаю, очень дискретное мышление? Попробую пояснить на примере. В ES6+ var остался, но практически все best-practices рекомендуют использовать const. В языках вроде Rust, F# и многих других надо принудительно указывать мутабельность, но она не очень приветствуется. Я это рассматриваю как постепенное движение к иммутабельности. А для вас факт поддержки переменных — это то, что они основы?
А там много не надо. Достаточно одного, чтобы большая часть рынка программистов осталась без работы.
И как этот переход в BASIC будет выглядеть? "Доброе утро, котятушки. Вчера я вам показывал рисование круга на BASIC. Но этот язык настолько убогий, кроме строк и чисел ничего не поддерживает, поэтому сегодня начнём изучать новый".
Ассемблером можно заинтересовать. Я в таких случаях использую embedded-платформы, от простых контроллеров, где можно помигать светодиодами, до чего-то роботизированного. Но это другой вектор развития.
Из всего богатого мира software engineering вы взяли только computer science, оттуда выдернули маленький кусочек, касающийся исключительно одной вычислительной модели, с уклоном на наиболее типовые микропроцессорные архитектуры и называете это основами программирования?
Я через десятилетия несу любовь к ассемблеру, что не мешало мне программировать от Рефала или Пролога до SQL, XSLT, выводке всяких ML, Gherkin и т.п., которые с недоумением смотрят на ваши выводы, отрицающие существование символьного, декларативного, мета- и других форм программирования.
Я так понимаю, что для вас Марков или Чёрч — это не основы, а НАМ или лямбда-исчисление недоразумение. Ну тогда я вам могу предложить основу ещё более основательную — машина Тьюринга. Не благодарите, получайте удовольствие. Говорят удачный вариант реализации в языке Brainfuck.
Мы опять говорим про переходы, которые многие из нас осуществляли в прошлом. Современный мир — это совершенно другие приоритеты. Циклы? Вы пропустили тот момент, когда вся индустрия испытывала дикую боль, поскольку циклы не масштабировались на многоядерные системы? Переменные? Вы остались в стороне от страшных пыток многопоточными приложениями и не заметили, что мир становится всё более иммутабельным?)) Всё сейчас заметно движется в сторону обогащения системы типов. Не успеете моргнуть, как вместо условий у вас будут dependent types. И сейчас у многих идёт конкретная ломка, как избавиться от этого старого императивного багажа, который больше не работает. А вы предлагаете продолжать его культивировать.
Нет. Я уже не раз написал, что именно я считаю, но видимо вы не читаете.
С точностью наоборот. В реальной жизни всегда приходиться оперировать со знакомыми объектами. Стейкхолдеры, как и дети, не будут разговаривать с вами на другом языке. А вот уже от привычных для них объектов можно идти в правильном направлении. Вы же считаете, что от системы типов BASIC плясать куда проще. Число, строка… в проекте на Python вам тоже этого хватает?
А в Rust отличные абстракции и нет наследования в принципе. Что будем делать с этим фактом?
Не хочу принижать этот проект и ваше в нём участие, но объективно я не могу рассматривать это факт. Я тоже попадал в сотни разных проектов. Были и с уродливой кодовой базой, включая процедурщину и мне в голову не придёт этот подход восхвалять. Может это какой-то выдающийся продукт, который кладёт ту же Java на лопатки и можно краем глаза где-то взглянуть? А может как я и предположил, у нас просто разный смысл кроется за аббревиатурой ООП. Я, например, многие практики OOD в SQL использую. Хотя там никакого привычного ООП и в помине нет.
Программы = алгоритмы + структуры данных (с) Никлаус Вирт. Да и алгоритмы — это тоже структуры данных (привет LISP/Scheme и классический курс SICP). BASIC решает только одну часть и решает почень осредственно. Можно учить ребёнка писать Circle(...) как мартышка. А можно научить его описывать структуру Circle, массив таких структур, выводить разным способом (все, чётные, сдвигать, масштабировать, находить самый маленький, большой и т.п.), добавлять новые виды, объяснить обобщение и так постепенно вывести на правильный трек. Желаю удачи с алгоритмами в BASIC. Обучал, знаю.
У вас странные критерии сравнения. На мой взгляд он кардинально отличается от других языков. Просто небо и земля. Схожесть только на самом примитивном уровне вроде рудиментарных алгоритмических примитивов. Возьмите любую натуральную задачу. Там где ученики оперирует знакомыми объектами. Пусть даже будет скучный вариант с шахматами. Конструкцию вроде
Figure = class … end;
Board: Array['a'..'h', 1..8] of Figure;
На Pascal я объясню за минуты. А представьте себе описание шахматного мира на BASIC. И попробуйте оттуда хоть что-то перенести в современность кроме нескольких for/if. А потом попробуйте из Pascal.
Когда я говорю о переносимости знаний, я не имею ввиду перенос словаря ключевых слов и примитивных конструкций. Я говорю о переносе опыта и образа мышления.
Я говорил про типо-ориентированное программирование. ООП только упомянул в примере и это не эквивалентные вещи.
Да и ООП в Си навалом. Если только вы не ограничены одной и далеко не самой лучшей реализацией (трио инкапсуляция+полиморфизм+наследование). Иначе советую немного расширить кругозор, обратиться хотя бы к автору идеи и посмотреть тот же Smalltalk. Вот из него в современность переехать с event-driven архитектурами было бы не в пример проще. Так что ООП — это скорее стиль мышления. Как вы организуете объекты предметной области. Он спокойно может выражаться в конвенции именования ваших функции и ограничиться использованием простых записей. Возьмем что-то из классики, например Postgres:
static bool bloom_contains_value(BloomFilter * filter, uint32 value)
Если потом посмотреть на имплементации в том же Rust, то будет складываться стойкое ощущение дежа вю. Из такого "не ООП" вы легко можете переехать в тип BloomFilter с методом ContainsValue. И обратно.
Приведите пример индекса без сортировки? Понятно, что реализация процесса в СУБД нагружена спецификой вроде page split, fill factor и т.п., но по сути — это сортировка. Откройте исходники того же Postgres и посмотрите, скажем, как делается ребилд.
А про разницу в плане количества дисковых операций я уже сказал. Планировщик запроса лучше вас решит, будет он использовать индекс или нет. Если у вас в базе пока только десять записей, он не станет делать лишние IO и тащить страницы с индексами. А если у вас их биллионы, то возможно вы уже давно переехали на колумнар и индекса вообще нет, а сортировка есть. В одном случае это B-tree, в другом — BRIN. Вы просто пытаетесь заменить абстракцию (СУБД сортирует и может сделать это множеством способов, включая использование имеющегося индекса), отдельно взятой реализацией. Это не верно, хотя бы согласно принципу DIP.
Зависит от преподавателя. На самом деле рекурсия даже более натуральна. Просто надо ребёнку не на факториале демонстрировать или числах Фибоначчи, а на простой операции подсчёта предметов в мешке.
У нас путь похожий, но выводы разные. Да я писал на BASIC ещё для ДВК-1, да потом без труда перешёл на Pascal (только писал на нём как на BASIC, потратив немало времени на выкорчёвывание стереотипов). После чего переход на C#/Java (я опять же говорю о качественном переходе) дался намного легче. Но мне и в голову не приходит мысль пытаться перенести эту пропахшую нафталином ностальгию в сегодняшний день. Или советовать кому-то повторять этот путь длиной в несколько десятилетий с постоянным ломанием парадигм, выбрасыванием в помойку старых наработок и т.п.
Время примитивного императивного мышления в духе for/if уходит. Когда сегодняшний ребёнок выйдет на рынок труда, там уже вовсю будет типо-ориентированное программирование, что-то в духе Haskell, Idris, Agda и т.п. И мой опыт подсказывает, что для детей оно даже более натурально. Структурирование игровых персонажей, исследование их поведения с применением того же ООП заходит лучше, чем скучные синтетические числовые/символьные задачи, на которых строится BASIC, из-за его убогой системы типов и модульности. Таких детей можно хоть завтра бросать на реальные бизнес-задачи. Может у вас другой опыт преподавания, поделитесь, будет очень интересно.
Что я могу перенести из него в сегодняшний день? Скажите мне. Я тогда вычту его из "всего" и мы получим ответ на интересующий вас вопрос "что надо забыть". И я надеюсь, мы говорим о навыках решения задач, которые формируются в наших нейросетях годами, а не схожести синтаксиса for или if. Вы реально считаете, что некоторый условный тинейджер, начавший с BASIC ничуть не проиграет другим, которые начали с Pascal или Smalltalk?
И как, сильно пригодилось? Я тоже прошёл весь этот путь, но мне и в страшном сне не придёт в голову учить своих… да даже чужих детей BASIC. Я преподавал, начиная от пятиклашек и выше. BASIC — тот случай, когда ты через некоторое время вынужден сказать "А теперь забудьте всё, что мы учили". Если автору так нужно что-то лаконичное и шустрое, то Turbo Pascal просто на голову выше.
Индекс это и есть сортировка. Планировщик запросов сам разрулит, будет ли он использовать готовый индекс, или отсортирует сам. Как говорит документация того же Postgres: "The required sorting might be achieved either by an explicit sort step, or by scanning the relation in the proper order using an index on the join key".
Что именно в случае dtexec мне надо было разжевать? Какие кнопочки в визарде SSMS нажимать, чтобы получить dtsx, дублировать сюда рекомендации по настройке? А код для запуска я вам дал, в своём же бенче dtexec. Плюс дал код для эксперимента с SqlBulkCopy, который давал лучшие результаты. Но с ним вы не справились. Ведь есть риск, что не получится испортить настолько, чтобы тайминг оказался хуже вашего god-варианта.
Тестовый стенд — это тот, на котором вы проводили свои тесты. Поскольку они у вас вообще не соответствуют правилам хорошего бенчмаркинга, оставалось следовать хотя бы одному правилу — тестировать всё в одинаковых условиях. Вы начали эти тесты и логичней сравнивать другие варианты запуская в вашей же среде. Тем более, я то уже тесты провел и на более медленном сетапе скорости намного выше.
Достаточно, спасибо. Даже поверхностный просмотр говорит, что зачем-то вместо SqlNative драйвера вы стали использовать OLEDB, соединение с Postgres вообще за DNS не видно, bcp вы настраивали и сделали батч на 10М записей и сравниваете с dtexec у которого по дефолту батч в 1000 раз меньше, буфер стоит 3М, MaxConcurrentExecutables/EngineThreads не использовались от слова вообще, запускали как я понимаю на Windows. Предвосхищаю, что сейчас начнётся демагогия, мол я должен был все настройки для вашей задачи и вашей же тестовой среды подготовить. Ведь это я претендую на статью, которая громогласно заявляет о том, что нашёл самое быстрое решение. И сразу с этим соглашусь. Да, кто-то должен провести нормальные тесты.
Я перешёл по ссылке в почте, которая отправляет сразу на комментарий. В тексте оного не было никакого намека на то, что статья обновлена. Да и обновлена она в худших традициях хабра. Здесь принято делать update-секции, а не фальсифицировать исходный текст. Мимо. Но можем свалить вину и на меня, я не против, по формальным признакам вы со всех сторон молодец.
"Длительные теоретичесие рассуждения"? Первое, что я сделал — провел тесты со своей стороны и опубликовал полученные тайминги как по dtexec, так по SqlBulkCopy. С учётом нормализации последний был быстрее вашего решения, первый — чуть медленнее, но я его вообще не настраивал. Что мне SSMS сгенерировал, то и воткнул, чтобы сформировать общую оценку. Мимо.
А вот в ответа на бенчи с мой стороны у вас полыхнуло и понеслись "длительные теоретические рассуждения". Мой самый-самый первый комментарий вам содержал удивление, что вы "не пробовали запустить dtexec CLI" и почти каждое сообщение пропитано идеей, что проще протестировать, чем болтать языком. Разжевал всё о dtexec. Что это, где лежит, как использовать. В итоге после длительного треда c вашей теоретической демагогией удалось таки прижать к стенке, но тут вы "мастерски" выкрутились… Мол герой что запустили, назло этому троллю-теоретизатору. Молодец))
На хабре ещё теплилась идея конструктивной дискуссии. И я подумал, что сообща разберёмся, почему в вашем случае SSIS работает намного медленнее чем у меня, может ли быть SqlBulkCopy и какие-то ещё способы быстрее и т.п. Но с вами это не получилось, так что да, смысла в дальнейшей полемике не вижу.
Поэтому бенчи я оформлю нормально и отдельной статьей. Мне как раз скоро надо несколько терабайт скоро перегнать, правда в обратном направлении и акцент на columnar, но затрону оба направления, в том числе попробую и ваш подход. Без иронии вам за него спасибо. У меня в голове он уже пробудил план набросать утилиту, которая будет использовать SqlBulkCopy, но в абстракцию IDataReader будет завернут пайп от постгреса, напрямую, без FS-посредников. А также попробовать какой-нибудь PL-язык, скажем Pl/Python + SQLAlchemy. Дата-саентисты часто вставляют гигантские DataFrame в самые разные СУБД, наверняка что-то должно быть.
Вы либо не понимаете термина "троллинг", либо просто у вас подгорело от того, что плохо разбираетесь в технической стороне вопроса. Скатиться до того, чтобы называть троллингом сугубо техническую информацию, когда я вам разжевал в деталях как оно работает? Даже если бы выяснилось, что я плохо себя представляю плачевность ситуации с ODBC-драйвером, скатываться в технической дискуссии до такого… Да вы, сударь, свинья.
Выложите где-нибудь dtsx, вывод dtexec и настройки postgres. Доверия вашим тестам — ноль. Я перепроверю.