ORM vs SQL

Здравствуйте, сейчас занимаюсь проектированием интернет-ресурса. Проект на нативном пхп. Набор данных схож с большинством популярных cms - материалы, категории, юзеры, роли, комменты, настройки и прочее. Будут конечно некоторые специфические моменты, но к делу они не относятся.

В рамках проектирования, нужно понять, что же выбрать для проекта с претензией на highload в будущем. Пока вижу 2 варианта:

1. ORM (в частности doctrine 2, т.к. достаточно много с ней работал, если посоветуете что-то еще буду очень признателен)
2. Самописный класс модели, с ассоциативными массивами, строителем запросов и моделями-детками, которые будут содержать некоторые доп методы для соответствующей сущности.

Вот на этой развилке пока и остановился, с orm как по мне работать очень удобно, но слышал не мало нелестных отзывов об ухудшении производительности. Хотелось бы вынести этот вопрос на публику, кто, что считает (само собой буду сам все тестировать по этому вопросу, но возможно сможете как-то облегчить мою задачу)

Добавлено через 34 минуты
Дополню. Еще 1 момент, который смущает в той же доктрине: выбрать сущность можно только целиком, если не использовать sql. Т.е. нет каких-то своих методов для выборки к примеру id, date колонок (а если нужны только они, то выбирать все к примеру 20 полей если не больше - очень не оптимально), для этого нужно юзать квери билдер, или я что-то упускаю.

0

Сообщение от mrseo для этого нужно юзать квери билдер, или я что-то упускаю

Ну да. Может я что-то тоже упустил, но Doctrine 2 по сравнению с той же Eloquent мне довольно убогой кажется.
Чуть запрос посложнее банального SELECT -- только Native спасёт.
Что же до

ORM vs SQL

То native-запросы будут предпочтительнее для high-load. Для действительно высоконагруженных систем всё в ход идёт. И жертвуют нормализацией таблиц в базе (это я где-то читал о Twitter) для оптимизации нагрузки и т.д. и т.п.
Не до жиру, быть бы живу, как говорится.

0

Сообщение от Para bellum Doctrine 2 по сравнению с той же Eloquent мне довольно убогой кажется

Как раз наоборот Сейчас Doctrine - лучшее, что существует для php.

Добавлено через 4 минуты
По теме - здесь палка в двух концах. Очевидно, что "голые" SQL запросы - более производительный вариант, только на поддержку такого кода потребуется гораздо больше сил. Ну и, соответственно, наоборот - ORM избавляет нас от рутинной работы, но как следствие - страдает производительность.

0

Custos, вполне может быть, что я просто что-то не усвоил. Но вот гляньте эту тему: Как в Doctrine указать сырой подзапрос для свойства?

Что в Eloquent решается просто, с Doctrine нужно на Native писать. А при более-менее сложном проекте дело не ограничивается простыми .
В Doctrine рекомендуют использовать Native-запросы. А зачем она мне тогда, если с этим и PDO нормально справляется?

0

Para bellum, сама "идеология" ORM состоит в том, чтобы нам максимально абстрагироваться от самого способа хранения информации. То есть нам абсолютно не важно как хранятся наши данные, осуществляются связи и т. д. Мы оперируем только сущностями, которые предусмотрены нашей бизнес-логикой. Если следовать этой идеологии, то мы не должны присваивать значения полям сущностей при помощи "сырых" запросов, но естественно, что не всегда это получается.

0

Ну да, это само собой (я про абстрагирование). Но иногда хочется одним запросом всё сделать. Например, посчитать сумму покупок и назначить процент скидки для клиента в CRM какой-нибудь.
Без этих самых "сырых" подзапросов придётся делать запрос в базу, получать сумму и только потом уже сохранять данные клиента.
Ладно, видимо я несколько ушёл от концепции ORM, в пользу оптимизации запросов.

Да и не вспомню сейчас, почему Doctrine меня тогда так раздосадовала, что до сих пор злой хожу.

0

если вы умеете сами писать запросы в страницу с использованием ключей то ORM вам явно не нужна
https://github.com/kenjis/php-orm-benchmark (ваши тормоза здесь)
из-за умников которые ее применяют, а они забывают про ключи explain
проекты тормозят
да, что вы я видел написанное меню, которое для вывода делало 700!!! запросов рекурсивно
и да оно отрабатывало на хорошем сервере, но таких надо по рукам и в начале научить запросы писать, а затем ORM использовать, если решат

0

Сообщение от Fedor Vlasenko а они забывают про ключи explain

Я не совсем понял. EXPLAIN -- для исследования запросов ведь, для последующего поиска оптимального решения? ORM и оптимизация вполне могут сосуществовать. Если ORM нормальная, конечно.

0

Сообщение от Para bellum ORM и оптимизация вполне могут сосуществовать

когда нужна скорость и свой план отработки запроса ORM вам здесь непоможет. Вы не глянули на тесты поссылке
И наверное не писали запросов в страницу и более. Так бы меня прекрасно поняли.
Выше я хотел отметить, что испрользуя ORM

Сообщение от Fedor Vlasenko забывают про ключи

Гордо бив в себя в грудь они говорят 'Это-же ORM и это круто', а когда данных становится много, кричат, что во всем виноватата база, железо и все, что угодно кроме неправильного подхода в проектировки приложения.
Не используется в сложных финансовых рассчетх и аналитике.

0

Сообщение от Fedor Vlasenko Вы не глянули на тесты поссылке

Глянул, сразу же.

Сообщение от Fedor Vlasenko И наверное не писали запросов в страницу и более. Так бы меня прекрасно поняли.

Я изначально не усвоил, что значит "запросы в страницу". Имеете в виду длинные и сложные запросы, оказывается.
Про них я и не говорю -- там однозначно только Native использовать, если нужно быстрое приложение.

0

Решил все-таки не использовать orm в данном проекте, т.к. хочу сделать макс выхлоп по быстродействию + закрепить некоторые нюансы по sql. Просто написал обертку для pdo (вместе с так называемым квери билдером), отэкстэндил от нее модели для разных сущностей и в них дописываю доп функции по выборкам.

0