NK
можно переписать на триллион подзапросов тока перфоманс такого решения будет сомнителен
ну можно спокойно под этот сценарий подцепить тот же даппер или еще чо-то похожее и не парить себе мозг
Size: a a a
2021 February 05
DS
А с EF/Hibernate'ом очень много возможностей людям на пустом месте создать себе проблем с N+1, вообще не обратив на это внимание
NK
EF подобные ORMы заточены прежде всего на операции с отдельными сущностями. Любые массовые запросы в них - это так или иначе проблемы и хитрости. Я уж молчу от эффект от lazy loading'а.
Change tracking и UoW особо не спасают, при этом жрут ресурсы как не в себя.
А главное правило при работе с большими реляционками - это всегда массовые запросы, если есть возможность, никаких отдельных запросов по сущностям, если без них можно обойтись.
Change tracking и UoW особо не спасают, при этом жрут ресурсы как не в себя.
А главное правило при работе с большими реляционками - это всегда массовые запросы, если есть возможность, никаких отдельных запросов по сущностям, если без них можно обойтись.
ну так да. и очень часто бизнес процессы завязаны на работу именно с отдельными сущностями
ΑZ
ну так да. и очень часто бизнес процессы завязаны на работу именно с отдельными сущностями
не обязательно сущность бзнесовая соответствует базовой
ΑZ
ну пример выше я тебе приел" Удалите всех юзеров с компаниайди такой-то"
DS
ну так да. и очень часто бизнес процессы завязаны на работу именно с отдельными сущностями
Это тоже проблема, лучше сразу проектировать под массовую обработку чего-либо. Спасает от кучи проблем в будущем
NK
Это тоже проблема, лучше сразу проектировать под массовую обработку чего-либо. Спасает от кучи проблем в будущем
пока ты проектируешь массовую обработку, конкурент накрудошлёпил вокруг ЕФа и отхавал кусок рынка)
DS
пока ты проектируешь массовую обработку, конкурент накрудошлёпил вокруг ЕФа и отхавал кусок рынка)
Это не сильно дольше сделать
DS
Не настолько дольше, чтобы это составляло конкуретное преимущество
NK
а какие-то массовые косяки дёргают разраба прям руками на боевой базе фигачит через SSMS
DS
А вот количество проблем и времени, когда придется чинить подобное решение из-за перформанса - вот оно уже роль сыграет
DS
Т.е. это обычно экономия пары дней сейчас, чтобы потом сдохнуть в рефакторинге вместо написания бизнес фич.
CD
Т.е. это обычно экономия пары дней сейчас, чтобы потом сдохнуть в рефакторинге вместо написания бизнес фич.
Но время имеет свойство дешеветь
DS
Но время имеет свойство дешеветь
Не в таких масштабах, чтобы это оказывалось оправдано.
Я вот встречался с такими кейсами, чаще случалось, что смысла в этой экономии особо не было с учетом дальнейших трудозатрат на исправление. (А в той компании, которую я вспоминаю, учет времени очень хорошо вели на задачах, это там было видно)
Имхо, это вообще странная иллюзия, что говнокод почему-то кардинально быстрее писать, чем что-то хоть как-то разумное
Я вот встречался с такими кейсами, чаще случалось, что смысла в этой экономии особо не было с учетом дальнейших трудозатрат на исправление. (А в той компании, которую я вспоминаю, учет времени очень хорошо вели на задачах, это там было видно)
Имхо, это вообще странная иллюзия, что говнокод почему-то кардинально быстрее писать, чем что-то хоть как-то разумное
p
попытка скрыть один механизм эмулирую совершенно другой
Да. Но все абстракции протекают. А такие огромные как БД - тем более
ΑZ
Да. Но все абстракции протекают. А такие огромные как БД - тем более
да, только есть говенные абстракции которые протекают безо сякой пользы
ΑZ
я тебе говорю, сравни: ASP.NET WebForms/MVC
ΑZ
и то и то две абстракциио дного и того же
ΑZ
от одной компании
p
Поэтому и не нужно пытаться скрыть все. Только лишь главную часть.