Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 53
Я не верил, что при 50к записях, порядка 6-7 джойнов для фильтрации, и затем 6-7 запросов eager loading могут быть такие тормоза.
А при 6-7 джойнах для фильтрации можно обойтись запросами через ORM? Честно говоря слабо верится. Мне кажется, что когда начинаются такие фильтрации — это звоночек проверить схему БД или переходить на прямое построение запроса, без магии ORM.
Схема БД — именно. Были бы магические поля реальными — проблемы бы не было.
Я почему-то думаю что тут идут запросы тупо на чтение, а стало быть тут вообще можно не заморачиваться с ORM. И тут споры data mapper vs active record и т.д. не особо помогут. С Data mapper вы получите тоже существенное падение производительности (если не рассматривать фишку той же доктрины агрегировать результаты выборок в отдельные DTO объекты почти без магии).
Вообще тут такой момент, использовать ORM оправдано только тогда, когда у наших объектов, на которые мы «мэпим релейшены», есть какое-то поведение, и оно используется. Подавляющее большинство людей использует active record тупо как row data gateway, вынося всю логику/поведение хорошо если в сервисы, так еще частенько в контроллеры (особенно это любят делать ребята с Yii). Вывод — не нужны им ORM.
Вообще тут такой момент, использовать ORM оправдано только тогда, когда у наших объектов, на которые мы «мэпим релейшены», есть какое-то поведение, и оно используется. Подавляющее большинство людей использует active record тупо как row data gateway, вынося всю логику/поведение хорошо если в сервисы, так еще частенько в контроллеры (особенно это любят делать ребята с Yii). Вывод — не нужны им ORM.
Описанная вами проблема — не проблема AR. Сами же говорите, запросы отрабатывают за доли секунды. Проблема в кривом преобразовании данных. И то, что в ларе это находится в одном месте, не делает сам паттерн плохим.
Да да, самописное разрудивание локалей и поддержка миграций… Эх… зачем фреймворки нужны…
Хватит пихать сою «крайне спорную» статью везде. А проблема преобразования сырых данных в объекты (hydration) так то будет в любом случае. В случае с Ларой накладные расходы конечно очень велики. Но возьмите и сделайте именно тут выборку без гидрации, не? (https://gist.github.com/anonymous/c3d7d713722f3559b922fd638454d03a)
Понятно же что, есть случаи когда нужна простота и удобство кода и скорость разработки, а есть случаи когда нужна производительность.
Понятно же что, есть случаи когда нужна простота и удобство кода и скорость разработки, а есть случаи когда нужна производительность.
Что-то мне подсказывает, что инвайт вы таки не скоро получите. И даже не потому, что мы тут быдло минусующее.
Миграции с использованием фреймворков выглядят проще, если мы говорим о проектах, под проектами я понимаю не «сайт-визитка», а хотя бы landing page или иной продукт, который разрабатывается командой, то «самописность» сначала нужно понять, потом простить и как-то жить. Время включения в проект нового человека в случае фреймворка зачастую значительно ниже, чем случай своего кода.
Ладно, другой вопрос, сколько времени у Вас займет написание REST-сервиса, без фреймворка?
P.S. Если Вам не приходится использовать фреймворк, это значит что он вам не нужен, но это совсем не означает, что вворачивать шурупы должны с кулака, только лишь потому что Вам это удается.
Ладно, другой вопрос, сколько времени у Вас займет написание REST-сервиса, без фреймворка?
P.S. Если Вам не приходится использовать фреймворк, это значит что он вам не нужен, но это совсем не означает, что вворачивать шурупы должны с кулака, только лишь потому что Вам это удается.
«Крайне спорную» это крайне мягкое утверждение :)
А я всегда говорю, что эти ваши фреймворки фигня на постном масле
Ну это вы «всегда» говорите до моменты вашего «взросления» до профессионального разработчика, который работает в команде и тестирует свой код. Как только вы перейдете в эту форму, очень скоро полюбите и фреймворки, и предлагаемые ими решения, и научитесь пакеты складывать в собственные фреймворки, и т.д.
За сим коментом, предлагаю не кормить этого товарища. ))
> Фреймворки для хоумпаджей. Пихать их куда не следует — плачевно.
Разговоров про пихать куда не следует не было. Фреймворки нужно пихать куда следует :)
> тестов именно кода не пишем
Что-то не хотелось бы пользоваться плодами ваших разработок
> У меня есть ядро своих сайтов.
Поздравляю, у вас фреймворк.
> Такое ощущение, что фреймворки писали школьники. Так все кострубато и непродумано.
Выложите ваш фреймворк («ядро для сайтов») на гитхаб и мы все узнаем как нужно продуманно что-то писать.
Разговоров про пихать куда не следует не было. Фреймворки нужно пихать куда следует :)
> тестов именно кода не пишем
Что-то не хотелось бы пользоваться плодами ваших разработок
> У меня есть ядро своих сайтов.
Поздравляю, у вас фреймворк.
> Такое ощущение, что фреймворки писали школьники. Так все кострубато и непродумано.
Выложите ваш фреймворк («ядро для сайтов») на гитхаб и мы все узнаем как нужно продуманно что-то писать.
Какой шикарный хабросуицид!)
Работаю в команде, так завелось, что тестов именно кода не пишем :) Лучше писать качественный код, а не тратить время на написание и поддержку тестов.
А тестируете?
Я перерос ваши фреймворки.
Я практически уверен, что вы еще не пользовались ни одним фреймворком для написания более-менее крупного проекта. Опровергните это утверждение, дайте ссылочку на исходники вашего крупного проекта без фреймворка и у меня вопросы к вам отпадут.
Какие серьезные проекты на фреймворках?
Практически все — topface.com к примеру. Миллионы пользователей, терабайты информации, фреймворк zf2.
тестов именно кода не пишем :) Лучше писать качественный код, а не тратить время на написание и поддержку тестов
Ну вот вы и признались в вашем уровне разработки )
Работаю в команде
Сколько в команде человек занимаются написанием кода и разработкой?
У меня есть ядро своих сайтов
Это вы про файл типа core/functions.php весом в десятки метров или про класс Core с сотнями методов внутри? Дайте ссыль на исходники, буду признателен. Сэкономим и ваше и мое время )
Закон дырявых абстракций :)
Абстракции на то и абстракции, что полной абстракции не выйдет получить. Так что «дырки» в них будут в любом случае, мы же в реальном мире живем. А если принять это за аксиому, то можно жить. Как никак, дырявая абстракция лучше чем вообще без абстракции (разумеется надо еще здравым смыслом пользоваться а не просто так их лепить).
Так напишите свой механизм заполнения пустых объектов данными из базы, сделайте его максимально легким и достаточно (но не более) функциональным, и будет вам счастье.
Что-то мне подсказывает, что если бы вы переопределили метод attributesToArray в Ваших тяжелых моделях, так, чтобы он возвращал действильно нужные вам поля, проблема бы исчезла
Я много раз спорил со знакомыми, пишущими на Laravel, что модель — это слой данных, который не должен ничего знать о том, в каком формате он будет представлен для пользователя, и все эти «implements JsonSerializable» у модели — это неверно. По мне, так данная статья еще раз это подтверждает.
А как связано то, что модель содержит метод сериализации и то что — «это слой данных, который не должен ничего знать о том, в каком формате он будет представлен для пользователя»? Наличие базового метода сериализации в объекте это же нормальное явление.
Тем более забавно как вы подтверждаете свою точку зрения опираясь на статью (> «По мне, так данная статья еще раз это подтверждает.») корень проблемы которой в ином. Хитро)
Тем более забавно как вы подтверждаете свою точку зрения опираясь на статью (> «По мне, так данная статья еще раз это подтверждает.») корень проблемы которой в ином. Хитро)
Действительно, как же связан метод «jsonSerialize» в модели с представлением этой модели в формате JSON)))
Нет, я не вижу ничего нормального, когда такие методы зашиты в модель. Грубо говоря, это аналогично (согласно моему мнению) тому, если в модели был бы метод «convertToHtml» с кусками html в нем. Для приложения на коленке такое, может, и сойдет, но не для чего-то серьезного.
Нет, я не вижу ничего нормального, когда такие методы зашиты в модель. Грубо говоря, это аналогично (согласно моему мнению) тому, если в модели был бы метод «convertToHtml» с кусками html в нем. Для приложения на коленке такое, может, и сойдет, но не для чего-то серьезного.
У вас типичная batch задача, такую стоило бы делать или средствами SQL, не прибегая к маппингу вообще (вне зависимости от того, AR это или DM), либо просто поставить её в очередь и обработать в отдельном потоке.
Резюме: AR не виноват, проблема в ошибочном выборе инструмента.
Резюме: AR не виноват, проблема в ошибочном выборе инструмента.
Автор же говорит, что СУБД отрабатывает быстро, задержки на уровне интерпретатора. При чем тут индексы?
Вы один из тех, кто любит все оптимизировать на этапе разработки? ) Давайте порассуждаем. Автор сказал:
Админкой, как правило, пользуется админ, а это значит 1 запрос раз в 5-10 секунд (в лучшем случае). В свете этих выводов 0.18с уже не кажутся такой серьезной задержкой.
В админке выводилась информация из базы
Админкой, как правило, пользуется админ, а это значит 1 запрос раз в 5-10 секунд (в лучшем случае). В свете этих выводов 0.18с уже не кажутся такой серьезной задержкой.
Нет. Я один из тех кто знает, что такое индексы в реляционных субд :)
Ок, спрошу по другому. У автора обращение к базе 0.18 с., а обработка результата этого обращения 49.82 с. Вопрос:
При чем тут индексы?
Я понимаю к чему вы клоните, но статья не об этом )
Ну проблема еще может быть не в индексах, а в самом запросе.
select street, number, name,REPLACE(REPLACE(REPLACE(REPLACE(REPLACE(phones, '?', ''),'+7','8'),')',''),'(',''),' ','') as phone
from person
Ну если 0.18с на запрос создает проблему, тогда народ начинает задумываться об оптимизации запросов и БД, до тех пор зачем тратить на это время? (К индексам это не относится, индексы как правило ставятся на автомате большинством проггеров)
Извините, я мало знаком с Laravel но там же вроде ORM Eloquent а не AR.
Или автор про сам паттерн активной записи в общем смысле?
Или автор про сам паттерн активной записи в общем смысле?
Eloquent это ORM + ActiveRecord. Конкретно у автора возникли проблемы именно с имплементацией тамошней реализации Active Record (конкретно мэппинг данных на объект), а не с ORM.
Проблема active record в общем смысле может быть сформулирована только как «его пихают частенько туда куда не надо», забывая как-то как люди пришли к этому паттерну.
Проблема active record в общем смысле может быть сформулирована только как «его пихают частенько туда куда не надо», забывая как-то как люди пришли к этому паттерну.
в рельс можно наткнуться на такую проблему но несколько в иных контекстах. Там AR не сильно обвешивает сам класс оберточный методами какие бы выполняли «лишние» запросы но при джойнах так или иначе может выйти похожая ситуация…
Пока что справляюсь силами ORM что и автору советую как то искать способ средствами ORM оптимизировать запросы или убрать лишние. Почти всегда такое удавалось.
p.s. Согласен что мне просто может не попадались серьезные задачи на 1000к запросов с 10 жойнами. Как-то избегал архитектурно )
Пока что справляюсь силами ORM что и автору советую как то искать способ средствами ORM оптимизировать запросы или убрать лишние. Почти всегда такое удавалось.
p.s. Согласен что мне просто может не попадались серьезные задачи на 1000к запросов с 10 жойнами. Как-то избегал архитектурно )
p.s. кстати есть финт, может в php/laravel так же можно. Создавать не объект AR а просто объект PHP. Изначально не вязанный к БД (poro — Plain Old Ruby Object) и уже потом результаты его работы (работы с копиями такого обьекта) писать в БД
А с чего вы взяли что ваша проблема в мутаторах? У вас проблема явно в другом месте.
Покажите код OrderFilter
Покажите код OrderFilter
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
От любви до ненависти — один шаг, или как я разлюбил магию в ActiveRecord