Comments 31
SQL - это то место, где будешь "ловить ножи", особенно с ИИ. Если руками пишешь (прямо проверяешь все хотя бы), да.
С ИИ так советовать.... будет красиво, опасно красиво. И потом будут статьи, код написанный ИИ сломали, инекция и т.п. А джуняндра скажет, это не я, это ИИ такая вот, "не сделала хорошо злая такая"
В Хибере действительно много сайд-эффектов, которые ещё и ведут себя по разному от версии к версии. В отчётах, например, он вообще не пригоден к использованию в виду сложных выборок и отсутствия cte.
Последнее время приходилось писать запросы на 300-500 строк, в чем очень хорошо помогал ИИ, и так же помогал оптимизировать эти запросы. Я просматривал план сам, оптимизировал все и потом просил оценить и оптимизировать ещё ИИ, время на написание этих запросов существенно сократилось.
Коллеги из параллельной команды, в .net правда, пытались использовать “всю мощь ОРМ” и получили плачевные результаты, сложные запросы, которые строила ОРМ безумно грузили БД и в частности дисковую систему и за большого количества последовательных чтений. Оптимизировать индексами такие запросы не удавалось, так как они имели большую вложенность на больших объемах данных.
лол
Базы это одна из тех сфер, где LLM должна работать ТОЛЬКО через обертку во избежание проблем
Сейчас ORM есть с минимальным оверхедом что по факту собирают те же самые sql-запросы из методов но БЕЗОПАСНО
Конкретно это с ORM легко обходится через механизм оптимистических блокировок (в простейшем случае - поле версии и его проверку в транзакции перед записью). Зато есть всякие обзерверы, хуки на события моделей и куча всего приятного. Это еще один уровень абстракций, про который нужно понимать его преимущества и недостатки.
А в SQL легко можно можно получить неконсистентное состояние объекта, потерянные обработчики зависимых объектов и прочее и прочее, либо придется написать свой маппер строки БД в объект и обратно и кучу лапши для технического обеспечения того, что в ORM идет из коробки, причем для каждого объекта свое. Я понимаю, "фатальный недостаток" и вот это все, но в итоге стоимость поддержки системы с хорошим и типовым набором библиотек дешевле, а разработка - проще.
Это лишь капля в море, если копнуть глубже всю экосистемку джавы, то там очень много инструментов которые делали чтобы упростить жизнь, но получилось что усложнили, поверх этого начали решать то что усложнили и усложнили ещё больше.то усложнили и усложнили ещё больше.
Вопрос во многом еще и в архитектуре: ORM имеет свойство протекать в бизнеслогику, а это нарушение изоляции - хранение стоит абстрагировать от использвоания. И это можно делать и с ORM, но кто ж так будет делать. При правильной нарезке слоев BLL/DAO/DAL на нижнем уровне вообще все равно что использовать, хоть файлы, хоть sql, хоть ORM (но зачем)
Простите, прочитал только заголовок.
Конечно есть смысл в ORM. Естественно, если брать в расчет объем работ с базой данных. И если ты собираешься дальше работать с этим кодом.
А если учитывать ИИ и не использовать обсуждаемые абстракции - верный путь к деградации. Через месяц ты уже не поймешь, что делает робот в твоем коде. Если сейчас понимаешь...
Так-то ИИ - это тоже кольцо всевластия, которое внушает владельцу, что без него нельзя писать код.
Такое ощущение что прочитал ии текст.
Никакой конкретики, хоть бы одну проблему разобрали детально.
Много воды. Однословные предложения, как у видео для сна с YouTube
По смыслу статьи.
ИИ и hibernate хорошо знает и все подводные камни в нём. Вряд ли тут есть большая разница.
Hibernate позволяет достаточно просто работать с вложенными доменными моделями. Сам следить что было изменено внутри модели и сохраняет только изменнные объекты. Можно больше сосредоточится на написании бизнес логики. В противном случае придётся писать достаточно трудоёмкий код по отслеживанию изменений или просто написать кучу мелких скриптов склеенных в сервисном слое. Читать и разбирать это потом та ещё забава.
Если модель простая и плоская в hibernate конечно смысла особо нет, пихать его в любой проект не стоит.
Вдумчивая нормализация баз данных при проектировании часто помогает решить проблему еще до ее возникновения. Да, я согласен, что я даже не совет дал, а как сова-стратег из анекдота про мышей, но все же: если проблема в ORM, то и чистый SQL запрос может не помочь, но очень часто это решается переосмыслением бизнес объектов и отношений между ними. Да, иногда надо подстроить бизнес сущности под нормализацию, но оно того стоит. Попробуйте глянуть на проблему под другим углом. Мне помогает.
Вообще странная статья немного. В названии orm, но внутри один лишь jpa. С примером автора из жизни столкнуться можно и используя обычный sql: технологический стек не имеет разницы, если два обновления наслоятся друг на друга. Это решается архитектурно оптимистичными блокировками.
Различные orm (в тч hibernate), сам ЯП Java, используем бд - это технологии. У любой технологии есть много подковырных и сложных моментов, которые неочевидны новичкам. Как гласит древняя истина, "использование orm не является антипаттерном. Слепое использование orm и нежелание в нём разбираться является антипаттерном"
Часто говорят, что писать SQL вручную и маппить ResultSet в модели через getXXX()/setXXX() — скучно и неудобно. Возможно. Но это всего лишь эмоции разработчиков.
Это не эмоции разработчиков. Ручной маппинг - это непаханное поле для граблей и ошибок. ORM делает маппинг за тебя и он даёт гарантию, что маппинг всегда корректный и там нет ошибок. В отличии от ИИшечки, кстати.
ORM - это та штука, которая не просто делает эту работу с гарантией, она ещё и здорово облегчает переделку/рефакторинг.
Вы забываете про тесты. Все обращения в БД можно вынести в отдельные классы, и их ещё протестировать, чтобы все маппинги были корректными. Ну и получаеться, что "ручной маппинг" на практике ни когда не создаёт проблемы. Наоборот, он позволяет более точно регулировать поток данных между БД и сервером приложений. Например для сущности "Клиент", можно создать несколько моделек: ClientRecord - для заполнения таблиц, ClientDetailsTopLevel - для заполнения верхнего уровня формы, CLientRow - для комбобокса. И повторю - это всё должно быть обставлено тестами, которые контрлируют корректность мапинга. И чем больше текстов, тем лучше. А ИИ их ОЧЕНЬ хорошо и быстро пишет
А можно использовать orm и не тестировать маппинг, ведь ты и так знаешь, как она работает. Тесты (юнит) вообще мне кажутся искуственной и редко применимой концепцией, т.к. отлавливаюит только предсказуемые ошибки, а не те, которые обычно случаются, или вообще ничего не ловят, т.к. при изменении кода меняются и ожидания от него. Теоретически можно написать тесты, которые полезны, но на практике это ощущается сложнее, чем сама программа.
Утверждал это ещё лет 10 назад. Ваши запросы или слишком простые, чтобы использовать на них hibernate, или слишком сложные, чтобы использовать на них hibernate.
ORM всегда много обещает, но потом не сдерживает ни одного своего обещания.
ORM была в своё время очень хороша, когда надо было быстро создавать однотипные проекты. Время выхода на рынок простого проекта было весьма коротким. Это очень нравилось бизнесу.
Но в моей практике практически любой проект который пережил год, начинал страдать от борьбы не со сложностью бизнес логики или кода, а от борьбы с ORM.
Первая жертва ORM - это производительность. Тупой инструмент не может учесть все нюансы, и генерирует плохой SQL. В итоге, чтобы исправить проблемы производительности, я пишу SQL в проекте с ORM. А Когда приходишь в в чужую церковь со своим уставом... начинаются проблемы.
База данных-это уже довольно высокоуровневый инструмент, и SQL уже является абстракцией невероятно высокого уровня. Вводить такую сложную абстракцию, как ORM, поверх уже довольно сложной абстракции считаю довольно глупым и самонадеянным поступком.
ORM всегда много обещает, но потом не сдерживает ни одного своего обещания.
Очень часто люди когда узнают что у меня кофе машина начинают говорить - ну как не надоело каждый месяц ее разбирать и чистить а то внутри все в плесени. А я смотрю на них и не понимаю о чем они говорят, потому что моя машина всегда чистая и не понимаю о чем они.
У мира .Net есть одна ORM которая прям ну песня. В 99% случаев - она работает и быстро и комфортно. И без нее немного неудобно поддерживать актуальность кода и бд (благо с ллмками эта проблема легче решаема). Но все мои даже пет проекты начинаются с подлючения EntityFramework.
Не знаю, как в .NET это делается, но если вы ни разу не писали псевдо-нативный SQL, который поддерживают все нормальные ORM, чтобы пофиксить или обойти проблемы, возникающие из-за неэффективной генерации запросов ORM-кой, то вы просто не писали нормальных сложных проектов с хитрой бизнес-логикой.
Эмм... EF генерит нормальный код. я же говорю, для 99% случаев - он нормальный и быстрый. Просто надо знать что и как делать. для оставшегося 1% приходится вызывать или вьюшки или процедуры и использовать orm как маппер.
Ну еще CTE не поддерживает. Хотя с последними обновами IAsyncEnumerable хз, возможно и завезли.
Проекты были большие. Но да не вот эти с конференций, где милионы милиардов одновременных конекшенов.
Для баланса - однажды тоже довелось сделать поддержку двух бд - oracle и ms sql. Но был c# + nhibernate. Все прошло гладко, за 3 часа. Но было это 3000 лет назад.
И как я уже писал недавно в коментах - на том проекте еще был store procedure api (как rest api, только хранимки). Из-за того что следил, чтобы код держали близко к старому стандарту типа sql 92 - потребовались незначительные изменения.
Продукт был в банковской сфере, кодили его 5 программистов. Это чтоб примерно понимать сложность.
Не то, что-то с таким подходом. Не доложно быть так. Не может нормальная технология лажать в методе из одной строки. Почему для обновления одного булевого поля вообще нужно знать про существование @DynamicUpdate? Почему простейшая операция зависит от таких нюансов? Почему, чтобы система работала надёжно, я должен помнить десятки подобных особенностей?
Это называется Leaky abstraction. https://en.wikipedia.org/wiki/Leaky_abstraction
Увы, из удобных высокоуровневых абстракций иногда подтекают их низкоуровневые детали реализации.
Но если рутину теперь выполняет ИИ практически бесплатно, то этот аргумент начинает стремительно терять силу.
И тогда возникает закономерный вопрос.
А если из ИИ подтечёт? :)
За ИИ нужно смотреть. И тут главное чтобы понимать что читаешь, и чтобы читать было просто.
ИИ сможет обложить свой код таким количеством тестов, которые погрузили бы меня в страшнейшее выгорание, если бы их писал я. Также ИИ прекрасно пишет функциональные, интеграционные и end-to-end тесты. Он может смоделировать все ваши бизнес-процессы в тестовой среде. А если ему дать ещё и MCP для базы данных, то он ещё и на проде вам всё промониторит в смоук-тесте. ИИ в мощных моделях иногда находит мне такие edge-кейсы, о существовании которых я дааже не догадывался. Поэтому ORM, как очень сильная абстракция над уже очень сильной абстракцией, которой является сам SQL, абсолютно бесполезна в наше время.
читал статью, а про себя думал - да это же один в один мой опыт с ReactJS - поначалу jsx завораживал, но когда дело дошло до асинхронных операций пришлось разбираться в неочевидных тонкостях, все эти саги и генераторы для простых вещей (не знаю как сейчас обстоят дела у реакта, это было лет 6-8 назад). но нельзя сказать что этот опыт был бесполезным - это были первые шаги в мир функционального программирования (чистые функции и тд).
С приходом ИИ для работы на клиенте тоже нужно менять мышление. Зачем придумали Angular и React (и прочие фреймворки)? Ответ: чтобы быстрее программировать. Чтобы малыми силами делать бОльшую функциональность. Но с ИИ это уже не нужно. А значит не нужны и Angular и React. Достаточно TypeScript, кастомные теги, и async-функции.
И это будет быстро, потому что это будет делать ИИ.
А TypeScript и async-функции чтобы проще читать.
вам виднее, я не стремлюсь писать быстрее - для меня это хобби и пишу только в удовольствие. (вайбкодинг тоже пробовал - поначалу поразило а потом по мере роста проекта появлялось куча нерабочего кода и т.д., я использовал локальные модели на процесоре в основом, скорость около 1 т/с 4Q qwen3.6 27b. пришел к тому что раз в несколько дней прошу ИИ изучить проект и предложить улучшения - часть из них заслуживает внимания.) после реакта я был в восторге от Elm, но для быстрого прототипирования вспотел переписывать сериализаторы/десериализаторы - как я понял Elm очень бы себя хорошо показал в командах где отдельно фронт/бэк и где уже есть спецификация апи. сейчас я в восторге от elixir - phoenix. (но любовь к js осталась, да и node.js оказалась популярной штукой и опыт с ним тоже не лишний).
Когда тебе нравиться работа - это очень хорошо. И похвально.
Но нужно воспитывать в себе ещё ответственность. Я поясню что это значит:
Нужно понимать для чего делается эта работа.
Нужно понимать за что платяться деньги.
Нужно понимать, что тому, кто платит деньги, не важно какие у вас технологии, и на сколько они красивы и замечательны. Ему важно заработать деньги, чтобы заплатить Вам ЗП.
А для этого ему важно чтобы программа работала,
Работала надёжно и быстро.
И чтобы можно было быстро добавлять новые фичи.
Поэтому у разработчика уровня сеньёр, профессиональный фокус ориентирован на сопровождение и развитие. На устойчивую к резвитию архитектуру. На то, чтобы архитектура позволяла быстро и просто добавлять новые фичи. И чтобы можно было быстро фиксить баги.
ORM — есть ли профит? Особенно когда по двору бегает ИИ-шка