Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 20
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 - для комбобокса. И повторю - это всё должно быть обставлено тестами, которые контрлируют корректность мапинга. И чем больше текстов, тем лучше. А ИИ их ОЧЕНЬ хорошо и быстро пишет
Утверждал это ещё лет 10 назад. Ваши запросы или слишком простые, чтобы использовать на них hibernate, или слишком сложные, чтобы использовать на них hibernate.
ORM всегда много обещает, но потом не сдерживает ни одного своего обещания.
ORM была в своё время очень хороша, когда надо было быстро создавать однотипные проекты. Время выхода на рынок простого проекта было весьма коротким. Это очень нравилось бизнесу.
Но в моей практике практически любой проект который пережил год, начинал страдать от борьбы не со сложностью бизнес логики или кода, а от борьбы с ORM.
Первая жертва ORM - это производительность. Тупой инструмент не может учесть все нюансы, и генерирует плохой SQL. В итоге, чтобы исправить проблемы производительности, я пишу SQL в проекте с ORM. А Когда приходишь в в чужую церковь со своим уставом... начинаются проблемы.
База данных-это уже довольно высокоуровневый инструмент, и SQL уже является абстракцией невероятно высокого уровня. Вводить такую сложную абстракцию, как ORM, поверх уже довольно сложной абстракции считаю довольно глупым и самонадеянным поступком.
Для баланса - однажды тоже довелось сделать поддержку двух бд - 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
Увы, из удобных высокоуровневых абстракций иногда подтекают их низкоуровневые детали реализации.
Но если рутину теперь выполняет ИИ практически бесплатно, то этот аргумент начинает стремительно терять силу.
И тогда возникает закономерный вопрос.
А если из ИИ подтечёт? :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
ORM — есть ли профит? Особенно когда по двору бегает ИИ-шка