EFCore.BulkExtensions содержит расширения для массовых операций в ef core.
Спасибо, буду иметь в виду, что они вообще есть. Но я немного про другое, вот пример:
using LinqToDB;
using (var db = new DbNorthwind())
{
db.Product
.Where(p => p.UnitsInStock == 0)
.Set(p => p.Discontinued, true)
.Update();
}
P.S. Если подскажете такое же для EF, буду благодарен. Сам всё равно останусь верен LINQ to DB, но есть коллеги, которые используют EF. Да, bulk insert в LINQ to DB тоже есть.
Все конечно так, но если Вам придет письмо с таким содержимым, то я уверен, в штаны наложите знатно:
Привет, $username$! С тебя списали 100500 рублей за то-то, то-то, то-то.
Надеюсь, со мной не случится ни того, ни другого :)
Когда я писал статью, в основном думал о том, что отправка письма часто менее важна, чем сохранение данных и, тем более, работоспособность системы для других пользователей.
Впрочем, есть же разумные способы как вообще не встречаться с такими проблемами. Мне они показались очевидными, поэтому не стал писать в статье.
Я сам лично этой проблемой не занимался, да и дело было года 4 назад. Но разработчик, которому я доверяю, сказал, что посмотрел на варианты и нормально работающего решения не было (именно в ASP.NET).
P.S. Да, для тестов, в итоге, какой-то тестовый LDAP и подняли, может даже тот, что вы упоминаете.
P.P.S. Если что, node.js стали использовать не только из-за этого случая :)
Как так — нет? Разве программа в Windows состоит из иерархически организованных компонентов
У нас, видимо, чуть разное понимание либо концептуальности, либо противоестественности :)
VB, в моём понимании ничего не ломает, а просто добавляет абстракции более высокого уровня.
А так ли уж естественна для web именно модель запрос-ответ?
Web — он очень разный.
К примеру, взять SPA
Я имею в виду общение с сервером. Если SPA работает в браузере, периодически отправляя запросы на сервер — почему бы и нет. Если фреймворк/библиотеки для SPA начинают работать с SSR таким образом, чтобы скрыть от разработчика то, что код может выполниться на сервере, а может на клиенте — жди беды. Disclaimer: я не против SSR как такового и беды иногда, наверное, можно и не дождаться :)
Web Forms как раз пытаются «скрыть» от разработчика то, что есть серверный код и клиентский код, которые работают по совершенно разным принципам. Там абстракции не то что дырявые, а туннельные… Что ведёт к попыткам их исправить с помощью новых абстракций. Я не зря про PostPreInit прикалывался. Если помните, в ранних версиях WebForms не было событий вроде PreInit и в сложных случаях, когда много вложенных сложных компонентов начинались «танцы» с тем, в каком событии нужно вызвать код, чтобы он отработал в нужный момент.
P.S. На всякий случай, если это не очевидно. Всё сказанное мной, естественно, моё личное мнение — если кому-то WebForms нравится, удобно, повышает продуктивность, позволяет писать более поддерживаемый код — почему бы и нет — и люди и задачи разные ¯\_(ツ)_/¯
Похоже, автор статьи либо не читает комментарии, либо просто не отвечает ¯\_(ツ)_/¯
Меня лично вполне устраивает .NET для бэка, а вот в качестве BFF у Node.js есть одно существенное преимущество — море готовых библиотек.
Дошло до смешного, в одном проекте нужна была интеграция с Active Directory, так вот для Node.js нашлась готовая библиотека, с которой можно было тестировать приложение без поднятия отдельного контроллера домена. А для .NET, как нетрудно догадаться, не нашлась…
P.S. Я не «адвокат» бэка на ноде, но для вычислений, наверное, можно извернуться за счёт вызова кода, написанного на других языках. Другой вопрос, зачем…
Про Visual Basic ладно, можно назвать это делом вкуса, но лично для меня выбор в пользу C# был очевиден.
WebForms был хорош для упрощения перехода в web-программирование windows-разработчиков. Но он же концептуально противоестественен для веба ¯\_(ツ)_/¯
P.S. Давно не следил, они там ещё PostPreInit не успели прилепить? :)
Немного :)
Часть из них была связана со сменой работы, часть — с неумолимым ходом времени, самая приятная последняя часть — с возможностью реализовать идеи, которые давно уже созревали в голове и помощью коллег, особенно force (как с идеями, так и с реализацией).
1. С++, MFC, ATL (windows-приложение, база MS SQL Server, интеграция с офисными приложениями через COM). Сейчас наборчик странноват, вряд ли кому-то интересны подробности, но это было больше 20 лет назад…
2. Visual Basic, VBA (и старый добрый MS SQL). До сих пор стыдно :) Но задачи такие были…
3. C#, WinForms (и… правильно — MS SQL, дальше увидите, куда меня это завело). Тогда .NET только вышел, было чертовски интересно его изучать и помогать в этом другим.
4. С#, ASP.NET (но почти без WebForms) и MS SQL, много MS SQL… В новой компании было принято изрядную часть логики писать в SQL… Не то чтобы я фанат такого подхода, но на пару лет втянулся. К тому же, в очень небольшом коллективе была крайне высокая концентрация крутых программистов и дизайнеров тоже (да, Andreika, я про тебя ;). За счёт этого, не самый лучший (на мой скромный взгляд) архитектурный подход работал хорошо и с точки зрения runtime (а там были десятки тысяч пользователей в день) и с точки зрения скорости разработки и даже не сильно стрёмно было поддерживать. Если вкратце — данные читались с FOR XML, трансформировались в HTML через XSLT, а записывались хранимыми процедурами. Но Bus Factor был не больше 2…
5. Далее было 2-3.5 (как посмотреть) смены стека на одной работе (за 10+ лет), хотя, спойлер — C# выжил.
5.1. ASP.NET WebForms (и да, MS SQL). Самый сложный проект на моей памяти с точки зрения количества форм и бизнес-логики. Надо было написать 300+ разных форм, причём дорабатывать и обсуждать с заказчиком в процессе. Если что — это была миграция всех приложений для сотрудников Нью-Йоркского профсоюза гостиничного бизнеса (от мейнфреймов до приложений на MS Access). Пришлось за месяц набросать фреймворк, который позволял и максимально быстро формы лепить и давал возможность быстро навешивать на них бизнес-логику (на C#, не подумайте, что я без логики на SQL уже не мог :). Тем и спаслись. Ну и, опять же, программисты хорошие. Позже я узнал, что этот проект уже пытались сделать до этого 3 конторы, но не смогли как раз из-за объёма (параллельно работать на мейнфрейме, который был ужасен и жрал за сопровождение доллары миллионами заказчик не хотел).
5.2. Потом, логично, был ASP.NET MVC (и сами знаете что). Ну, тут ничего нового не расскажу.
5.2.5. Потом попалось несколько проектов, где можно было поэкспериментировать с технологиями. Там был, как обычно, C# и MS SQL, но попробовали и ServiceStack (жутко неудобно) и Angular (ещё 1.x)… Потом был проект для компании, назовём её «Росэлектрон» где с force решили-таки закопать REST и пользоваться чем-то вроде JSON-RPC (самописным), используя node.js в качестве BFF (но мы только потом узнали это модное слово).
5.3. Теперь используем связку .NET Core + node.js, фронтенд по-разному (где-то React+TypeScript, где-то jQuery), что-то вроде самописного gRPC (да, да,… но когда начинали делать gRPC только начинался и много не хватало), а в качестве БД — MS SQL или, внезапно, PostgreSQL.
Полёт нормальный, за почти уже 4 года наросло много приятных плюшек (к сожалению и технические долги есть, боремся), но про них не буду, потому что платформа закрытая (по крайней мере, пока).
P.S. Сорри за длинный и немного сумбурный комментарий — так совпало, что я в отпуске и меня несколько раз отвлекали :)
Поиграйся ещё и с github.com/lemire/SIMDCompressionAndIntersection тогда — там и Intersect есть, который тебе пригодится ;)
Понятно, что в чистом виде не подойдёт, вопрос самого подхода — насколько память сэкономит.
Для такого deep legacy (звучит как заголовок порно-ролика) можно сделать отдельную таблицу с иерархией «сбоку». Да, дополнительный join, зато можно гибко настроить иерархию (или даже несколько).
Если такое легаси, что даже с этим сложности — остаётся только посочувствовать…
Бывает вот такое:
— PM: У нас иерархия будет 100% статична, ничего там меняться не будет!
— TL: Давайте Nested Set, а заодно сэкономим поля и объединим ID/left.
…
— PM: А давайте теперь дадим пользователю настраивать иерархию самому!
:)
Так а в чём проблема с редактированием nested set? Главное, как я уже говорил, чтобы не требовалось оптимизировать больше вставку чем чтение. А это крайне редко требуется.
Строго говоря, я вижу два варианта:
— мы со страшной силой пишем что-то, например, с датчиков и непременно в иерархию (повод задуматься о специализированном хранилище);
— требуется выпрямить руки программистам, которые небрежно спроектировали решение.
В остальных случаях, nested set будет работать нормально. Для более экзотических случаев (или экзотических разработчиков, которым вдруг сложно будет с ним разобраться) можно что-то ещё придумать.
Если интересно — зайдите на redmine.org — там вполне себе иерархические задачи на nested set и (ой!) они редактируются ;)
P.S. Может, это вообще всё сильно субъективно, но лично я между CTE со склейкой id на простой структуре БД и nested set с нетривиальной логикой по вставке выберу nested set.
Сочувствую. Вдруг пригодится — из свежих метаисследований: www.ncbi.nlm.nih.gov/pmc/articles/PMC5169082 (там много, можно для начала пройтись поиском по «angina» или summary почитать).
Disclaimer: я не врач, я просто разместил объяву даю информацию к размышлению.
Да, ещё информация к размышлению от Талеба (если интересно — источник Harry Bakwin “Pseudoxia pediatrica”, 1945):
Рассмотрим необходимость «сделать что-нибудь» на показательном примере. В 1930-х годах нью-йоркские врачи осмотрели 389 детей; 174 из них была рекомендована тонзиллэктомия – удаление нёбных миндалин. Оставшихся 215 детей вновь повели к другим врачам, и те постановили, что 99 из них нуждаются в операции. Когда оставшиеся 116 детей посетили третий состав врачей, хирургическое вмешательство рекомендовали лишь пятидесяти двум из них. Если учесть, что в удалении миндалин на деле нуждаются 2–4 процента детей (сегодня, а не в 30-х, когда риск осложнений был куда больше), а также что одна из 15 тысяч таких операций заканчивается смертью пациента, становится ясно, где расположена точка безубыточности между прибылью медиков и ущербом для здоровья.
О! Как раз к Цифран СТ и читал инструкцию. Почему мне не назначили что попроще — не понимаю (видимо, «чтобы наверняка» или «потому что так принято»). Почему я его вообще купил раз я «такой умный»? Просто немного плохо думалось сразу после удаления зуба :)
По поводу меньшего из зол — это подкреплено чем-то (результатами исследований на pubmed), кроме рекомендаций? Я к тому, что в статье, которую приводил, говорили о недоказанности пользы от применения антибиотиков в большинстве случаев. Ещё тогда читал (не смог сходу найти, может это уже опровергли), что при приёме внутрь антибиотиков концентрация действующих веществ в полости рта слишком маленькая.
P.S. Видимо, в следующий раз перед удалением зуба надо предварительно самому поискать :)
— Помимо вышеперечисленных рекомендаций назначаются лекарства, так называемая антибактериальная и противовоспалительная терапия. Обусловлено это тем, что область операции крайне легко воспаляется и нагнаивается, а нам бы этого не хотелось. Поэтому пренебрегать этой рекомендацией НЕЛЬЗЯ. Вместе с приёмом антибиотиков отлично заходят...
Можно подробнее про это? Какие антибиотики сами назначаете?
Не будет ли дороже, но правильнее чаще отслеживать состояние вместо антибиотиков «по умолчанию»?
Почему спрашиваю. Сам после удаления зуба, фигурально выражаясь, держал в одной руке натуральный свиток с перечислением побочных эффектов к назначенному антибиотику (и многие вероятности были 1/10-1/100, что не вдохновляло), а другой рукой искал информацию в интернете :) Нашёл, в частности, вот эту (правда, старую) переводную статью.
В результате, пить антибиотики не стал. Сходил лишний раз (или два) в клинику, чтобы посмотрели на процесс заживления.
Disclaimer: я не врач и, возможно, с точки зрения последних исследований, неправ. Но тогда интересно узнать про последние исследования.
С первым пунктом все тривиально: если текст ошибки вам совсем непонятен — копируете его в гугл, и вдумчиво читаете текст по ссылкам.
Практика показывает, что не всегда тривиально. Или стоит уточнить определение «вдумчиво читать» :)
Я бы добавил — «Если нашёл ответ в интернете, убедись, что понял его».
Потому что встречаются любители SODD — код тупо скопировали, а потом сюрпризы на ревью случаются (и хорошо, если на ревью)…
TL&DR; есть спорные моменты, но в целом статья интересная. Чем больше вариантов архитектур — тем лучше.
Дополнил статью этой информацией.
P.S. LINQ to DB нравится не только массовыми операциями.
Спасибо, буду иметь в виду, что они вообще есть. Но я немного про другое, вот пример:
P.S. Если подскажете такое же для EF, буду благодарен. Сам всё равно останусь верен LINQ to DB, но есть коллеги, которые используют EF. Да, bulk insert в LINQ to DB тоже есть.
Надеюсь, со мной не случится ни того, ни другого :)
Когда я писал статью, в основном думал о том, что отправка письма часто менее важна, чем сохранение данных и, тем более, работоспособность системы для других пользователей.
Впрочем, есть же разумные способы как вообще не встречаться с такими проблемами. Мне они показались очевидными, поэтому не стал писать в статье.
P.S. Да, для тестов, в итоге, какой-то тестовый LDAP и подняли, может даже тот, что вы упоминаете.
P.P.S. Если что, node.js стали использовать не только из-за этого случая :)
У нас, видимо, чуть разное понимание либо концептуальности, либо противоестественности :)
VB, в моём понимании ничего не ломает, а просто добавляет абстракции более высокого уровня.
Я имею в виду общение с сервером. Если SPA работает в браузере, периодически отправляя запросы на сервер — почему бы и нет. Если фреймворк/библиотеки для SPA начинают работать с SSR таким образом, чтобы скрыть от разработчика то, что код может выполниться на сервере, а может на клиенте — жди беды. Disclaimer: я не против SSR как такового и беды иногда, наверное, можно и не дождаться :)
Web Forms как раз пытаются «скрыть» от разработчика то, что есть серверный код и клиентский код, которые работают по совершенно разным принципам. Там абстракции не то что дырявые, а туннельные… Что ведёт к попыткам их исправить с помощью новых абстракций. Я не зря про PostPreInit прикалывался. Если помните, в ранних версиях WebForms не было событий вроде PreInit и в сложных случаях, когда много вложенных сложных компонентов начинались «танцы» с тем, в каком событии нужно вызвать код, чтобы он отработал в нужный момент.
P.S. На всякий случай, если это не очевидно. Всё сказанное мной, естественно, моё личное мнение — если кому-то WebForms нравится, удобно, повышает продуктивность, позволяет писать более поддерживаемый код — почему бы и нет — и люди и задачи разные ¯\_(ツ)_/¯
Когда я говорил про концептуальную противоестественность, подразумевал замену естественной для web'а модели запрос-ответ циклом событий.
Меня лично вполне устраивает .NET для бэка, а вот в качестве BFF у Node.js есть одно существенное преимущество — море готовых библиотек.
Дошло до смешного, в одном проекте нужна была интеграция с Active Directory, так вот для Node.js нашлась готовая библиотека, с которой можно было тестировать приложение без поднятия отдельного контроллера домена. А для .NET, как нетрудно догадаться, не нашлась…
P.S. Я не «адвокат» бэка на ноде, но для вычислений, наверное, можно извернуться за счёт вызова кода, написанного на других языках. Другой вопрос, зачем…
Про Visual Basic ладно, можно назвать это делом вкуса, но лично для меня выбор в пользу C# был очевиден.
WebForms был хорош для упрощения перехода в web-программирование windows-разработчиков. Но он же концептуально противоестественен для веба ¯\_(ツ)_/¯
P.S. Давно не следил, они там ещё PostPreInit не успели прилепить? :)
Вот что забыл спросить — с каким .NET'ом сравнивали и что именно значит «прожорливость»?
Немного :)
Часть из них была связана со сменой работы, часть — с неумолимым ходом времени, самая приятная последняя часть — с возможностью реализовать идеи, которые давно уже созревали в голове и помощью коллег, особенно force (как с идеями, так и с реализацией).
1. С++, MFC, ATL (windows-приложение, база MS SQL Server, интеграция с офисными приложениями через COM). Сейчас наборчик странноват, вряд ли кому-то интересны подробности, но это было больше 20 лет назад…
2. Visual Basic, VBA (и старый добрый MS SQL). До сих пор стыдно :) Но задачи такие были…
3. C#, WinForms (и… правильно — MS SQL, дальше увидите, куда меня это завело). Тогда .NET только вышел, было чертовски интересно его изучать и помогать в этом другим.
4. С#, ASP.NET (но почти без WebForms) и MS SQL, много MS SQL… В новой компании было принято изрядную часть логики писать в SQL… Не то чтобы я фанат такого подхода, но на пару лет втянулся. К тому же, в очень небольшом коллективе была крайне высокая концентрация крутых программистов и дизайнеров тоже (да, Andreika, я про тебя ;). За счёт этого, не самый лучший (на мой скромный взгляд) архитектурный подход работал хорошо и с точки зрения runtime (а там были десятки тысяч пользователей в день) и с точки зрения скорости разработки и даже не сильно стрёмно было поддерживать. Если вкратце — данные читались с FOR XML, трансформировались в HTML через XSLT, а записывались хранимыми процедурами. Но Bus Factor был не больше 2…
5. Далее было 2-3.5 (как посмотреть) смены стека на одной работе (за 10+ лет), хотя, спойлер — C# выжил.
5.1. ASP.NET WebForms (и да, MS SQL). Самый сложный проект на моей памяти с точки зрения количества форм и бизнес-логики. Надо было написать 300+ разных форм, причём дорабатывать и обсуждать с заказчиком в процессе. Если что — это была миграция всех приложений для сотрудников Нью-Йоркского профсоюза гостиничного бизнеса (от мейнфреймов до приложений на MS Access). Пришлось за месяц набросать фреймворк, который позволял и максимально быстро формы лепить и давал возможность быстро навешивать на них бизнес-логику (на C#, не подумайте, что я без логики на SQL уже не мог :). Тем и спаслись. Ну и, опять же, программисты хорошие. Позже я узнал, что этот проект уже пытались сделать до этого 3 конторы, но не смогли как раз из-за объёма (параллельно работать на мейнфрейме, который был ужасен и жрал за сопровождение доллары миллионами заказчик не хотел).
5.2. Потом, логично, был ASP.NET MVC (и сами знаете что). Ну, тут ничего нового не расскажу.
5.2.5. Потом попалось несколько проектов, где можно было поэкспериментировать с технологиями. Там был, как обычно, C# и MS SQL, но попробовали и ServiceStack (жутко неудобно) и Angular (ещё 1.x)… Потом был проект для компании, назовём её «Росэлектрон» где с force решили-таки закопать REST и пользоваться чем-то вроде JSON-RPC (самописным), используя node.js в качестве BFF (но мы только потом узнали это модное слово).
5.3. Теперь используем связку .NET Core + node.js, фронтенд по-разному (где-то React+TypeScript, где-то jQuery), что-то вроде самописного gRPC (да, да,… но когда начинали делать gRPC только начинался и много не хватало), а в качестве БД — MS SQL или, внезапно, PostgreSQL.
Полёт нормальный, за почти уже 4 года наросло много приятных плюшек (к сожалению и технические долги есть, боремся), но про них не буду, потому что платформа закрытая (по крайней мере, пока).
P.S. Сорри за длинный и немного сумбурный комментарий — так совпало, что я в отпуске и меня несколько раз отвлекали :)
Понятно, что в чистом виде не подойдёт, вопрос самого подхода — насколько память сэкономит.
Если такое легаси, что даже с этим сложности — остаётся только посочувствовать…
P.S. Для Cobol есть драйвер для PostgreSQL? :)
А nested set — он клёвый, там ещё и порядок детей задаётся «из коробки».
P.S. Вообще, далеко ушла дискуссия в статье, начинающейся со слов «PostgreSQL Antipatterns» :)
Так а в чём проблема с редактированием nested set? Главное, как я уже говорил, чтобы не требовалось оптимизировать больше вставку чем чтение. А это крайне редко требуется.
Строго говоря, я вижу два варианта:
— мы со страшной силой пишем что-то, например, с датчиков и непременно в иерархию (повод задуматься о специализированном хранилище);
— требуется выпрямить руки программистам, которые небрежно спроектировали решение.
В остальных случаях, nested set будет работать нормально. Для более экзотических случаев (или экзотических разработчиков, которым вдруг сложно будет с ним разобраться) можно что-то ещё придумать.
Если интересно — зайдите на redmine.org — там вполне себе иерархические задачи на nested set и (ой!) они редактируются ;)
P.S. Может, это вообще всё сильно субъективно, но лично я между CTE со склейкой id на простой структуре БД и nested set с нетривиальной логикой по вставке выберу nested set.
Nested set не самый удобный подход с точки зрения вставки, но не всё так плохо — id там менять не надо.
Disclaimer: я не врач, я просто
разместил объявудаю информацию к размышлению.Да, ещё информация к размышлению от Талеба (если интересно — источник Harry Bakwin “Pseudoxia pediatrica”, 1945):
По поводу меньшего из зол — это подкреплено чем-то (результатами исследований на pubmed), кроме рекомендаций? Я к тому, что в статье, которую приводил, говорили о недоказанности пользы от применения антибиотиков в большинстве случаев. Ещё тогда читал (не смог сходу найти, может это уже опровергли), что при приёме внутрь антибиотиков концентрация действующих веществ в полости рта слишком маленькая.
P.S. Видимо, в следующий раз перед удалением зуба надо предварительно самому поискать :)
Можно подробнее про это? Какие антибиотики сами назначаете?
Не будет ли дороже, но правильнее чаще отслеживать состояние вместо антибиотиков «по умолчанию»?
Почему спрашиваю. Сам после удаления зуба, фигурально выражаясь, держал в одной руке натуральный свиток с перечислением побочных эффектов к назначенному антибиотику (и многие вероятности были 1/10-1/100, что не вдохновляло), а другой рукой искал информацию в интернете :) Нашёл, в частности, вот эту (правда, старую) переводную статью.
В результате, пить антибиотики не стал. Сходил лишний раз (или два) в клинику, чтобы посмотрели на процесс заживления.
Disclaimer: я не врач и, возможно, с точки зрения последних исследований, неправ. Но тогда интересно узнать про последние исследования.
Практика показывает, что не всегда тривиально. Или стоит уточнить определение «вдумчиво читать» :)
Я бы добавил — «Если нашёл ответ в интернете, убедись, что понял его».
Потому что встречаются любители SODD — код тупо скопировали, а потом сюрпризы на ревью случаются (и хорошо, если на ревью)…
P.S. А статья, в целом — отличная.