Кисель в Айти | Python разработка
02.06
Недавно читал статью про оптимизацию PostgreSQL. Там была фраза "Пишите запросы вручную, ORM переоценён". Причём статейка подаётся как от "разработчика к разработчикам", но как такой "совет" может дать человек в здравом уме - не понимаю. Тут мол вам и n+1, и кривые джойны, и магия "под капотом". Ну чтож, разберёмся чуть подробнее.
Проблема с N+1 - явно надуманная и решается на любой ORM без танцев с бубном. Джойнится всё в большинстве случаев самым оптимальным образом. Если вдруг нет - обычно всё решается небольшими изменениями в коде и достаточно предсказуемо. Вот про магию под капотом так вообще хохма. Давайте вспомним зачем нужна ORM? Для работы с данными, как с объектами. Это абстракция над SQL. Чтобы думать про то, что сделать, а не "как". Это буквально придумали для того, чтобы снизить сложность.
В тот момент, когда человек по любому чиху бежит писать запросы на чистом SQL мы буквально гвоздями себя приколачиваем к текущей схеме данных. Редачить даже десяток сырых запросов после каждого изменения схемы - вот это настоящий ад. Даже если всё покрыто тестами (а оно не всегда покрыто). В добавок сырые запросы дико проиграют по читаемости. Попробуй еще сообрази, что там происходит и что мы получим. А что получаем в замен? Возможно ощущение, что "мы молодцы, умеем в sql", ну и собственно всё.
Так что перед тем, как писать сырой SQL нужно явно убедиться, что задача реально недостижима при помощи ORM. Иначе - это неоправданное переусложнение.
· 03.06
Ну или myBatis или jooq или Spring Data JDBC. Для повышения читаемости. А вот магия под капотом оно вроде бы строит запросы оптимально в 99% но 1 % порой так жизнь портит. Ну и еще часто встречается что модель требует 4 и более уровней вложенности - тут тоже как-то с Hibernate задача несколько не удобная.
ответить
еще контент в этом сообществе
еще контент в этом соообществе
Кисель в Айти | Python разработка
02.06
войдите, чтобы увидеть
и подписаться на интересных профи