Comments 18
Они эффективно обрабатывают отношения между таблицами, автоматически загружая связанные элементы при извлечении записей с отношениями 1:m, избавляя от необходимости выполнять дополнительные запросы вручную.
Они скорее неэффективно создают связывающие запросы выполняя зачастую ненужные дополнительные запросы автоматически под капотом так, что у DBA потом волосы дыбом.
Почему-то подумалось, что в статье речь пойдет про агрегаты.
Для максимальной производительности наверное не надо использовать никакой ORM. Но я знаю, что я в меньшинстве.
Никак нет. Вы в большинстве. Но когда идет разговор про стоимость часа разработки, то вспоминают про ОРМ - они же в CRUD себя неплохо показывают? А что будет, когда логика перестает быть CRUD? На этом моменте всем не важно, главное стоимость часа, и время.
ОРМ это скорее плохо. Но если вы пишете записную книжку, или что-то документ-ориентированное - ОРМ вам помощник.
P.S. И еще ОРМ снижает ФЗП. Зачем платить разработчику со знанием SQL, когда можно взять разработчика без знания SQL?
Брать человека не знающего SQL, для работы с БД - это уровень фразы "просчитался, но где".) Большинство ORM по умолчанию даже нормальное индексирование не делают, о чём человек, не знающий SQL знать не будет, как и банально не сможет написать специфический функционал.)
Очень интересно, что вы имеете в виду под "нормальным индексированием"
Индексы на foreign key? Питоновский ORM django делает.
Хотел написать нормальной оптимизацией, но почему-то в голове думал про индексы и вышло, что вышло. Имел ввиду, ORM любят генерировать неоптимизированные запросы (например частая проблема избыточные JOIN), загружать избыточные данные, создания большого количества промежуточных объектов и т.д. И это всё не касаясь индексов.
Вы какую-то чушь здесь написали. ORM, который "не требует знания SQL" - это тот самый CRUD на 4 запроса. Людей, которые занимаются веб-программированием не зная SQL на этом уровне, можно себе представить только в полемических фантазиях.
При этом для любого чуть более сложного запроса ORM надо понимать, как его писать. Даже с использованием ORM. Тупо на уровне какие ключевые слова писать.
Не всегда. Это примерно как Rust vs Assembly. В теории (и на практике) можно написать Low-Level код, который бы работал быстрее и эффективнее ORM, однако на практике же при масштабировании без наличия UoW, Identity Map (IM), всяких ленивых "where in" отношений и прочего можно запросто получить большую мусорку, особенно когда общение начинается между разными контекстами через какую-нибудь шину и одна часть системы, реагирующая на какое-то событие/команду не знает ничего о другой.
Ну, например, аутентификационная инфраструктура дёргает юзера, а потом где-то в апп сервисе он же дёргается через репозиторий уже. Без IM получим лишний запрос сразу (а то и несколько, если юзер тянет за собой ещё что-то).
Так что я бы переформулировал как "для максимальной производительности, при наличии свободного времени написать половину того, что есть в ORM и достаточной квалификации".
Нет, не в меньшинстве.)
ORM по большей части используется для удобства и стандартизации работы с бд, а не ради производительности. Поэтому, как всегда всё сводится к поиску золотой середины под каждый проект в отдельности.
Почему-то всегда дихтомия, или-или. Или штепсель вдребезги, или розетка пополам. Почему не вместе-то?
90% кода типичного веб-приложения и так не вызывает никаких проблем с производительностью. Получить запись по первичному ключу. Получить полсотни записей простым джойном. Такого рода операции либо вообще не требуют никакой "оптимизации", либо прекрасно оптимизируются средствами ORM. Но при этом объём и время написания кода сокращаются в разы.
При этом действительно тяжёлые случаи никто не запрещает переписать на чистый SQL. Если цель - быстро разработать стабильно работающее приложение, а не устроить очередной холивар.
Ещё есть cycle orm
А что разработчики вообще разучились в pdo и хотя бы middle уровень sql запросов?
Да уж, скоро no-code во всей красе выплюнется
Статья - редкая халтура.
Сочинение студента-двоечника, чтобы препод откопался. На вопрос "как выбрать" не отвечает вообще никак. Ну только если не считать ответом классические камлания "выбор - вопрос сложный, к нему надо подходить ответственно". Плюс обязательная отсебятина и пять кубометров воды.
Ещё статья до боли напоминает индусский спам, который одно время потоком шёл на Реддите, буквально по 2-3 поста в неделю: как выбрать фреймворк, как выбрать ORM, как выбрать язык... При этом отличительные особенности каждого из продуктов берутся от балды, без какой-либо системы или привязки к реальности. Что неудивительно, поскольку для написания реальной статьи надо все эти продукты знать. А этим может похвастаться далеко не каждый профессиональный разработчик.
В итоге вместо осмысленного выбора мы получаем мычание, общие слова про ORM, равномерно размазанные по всем трем участникам соревнований:
Про Доктрину написано, что она "предлагает расширенные возможности для написания запросов и поддерживает транзакции и кэширование". Как будто другие две этого не предлагают.
"Eloquent предлагает удобный API для выполнения операций: запросов, вставок, обновлений и удалений записей, а также поддерживает быстрое извлечение данных и управление взаимосвязями". Ну просто киллер-фича, отсутствующая в других библиотеках.
Про Propel указано, что она "построена на основе PDO". Это, конечно, сразу выделяет её на фоне остальных! А также высокая производительность. Птица-говорун отличается умом и производительностью. И популярностью. Вот только почему-то "медленную" Доктрину устанавливают в 50 раз чаще, чем "быстрый" Пропель. У которого статистика использования говорит о популярности на уровне поддержки легаси проектов.
Собственно, отдельные элементы статьи наводят на мысль, что исходно это и есть небрежно переведённый индусский спам. "Чтобы получить электронное письмо от пользователя", ага.
Очень жаль, что компания решила войти вайти на Хабр с такой позорной халтурой. Если вы действительно такие монстры, то у вас должен быть миллион реальных юзкейсов, про которые и надо писать статьи. Ну а если вы только ещё собираетесь становиться монстрами, то стоит сначала немного подучить матчасть, а потом уже пытаться делиться своими знаниями с окружающими.
PHP и работа с базами данных: как выбрать и использовать ORM для максимальной производительности