Комментарии 31
Спасибо — думаю, пригодится.
Как со скоростью?
»»запросы по ключам тянут по 1 записи
— это ужасно.
я бы сделал (да и часто так делаю) — после получения данных из основной таблицы, пройтись по результатам, собрать нужные айдишники и через WHERE IN их повыдергивать, потом собрать в цикле.
тогда кол-во запросов сокращается до кол-ва ключей, а не равняется кол-ву ключей, помноженному на кол-во записей.
— это ужасно.
я бы сделал (да и часто так делаю) — после получения данных из основной таблицы, пройтись по результатам, собрать нужные айдишники и через WHERE IN их повыдергивать, потом собрать в цикле.
тогда кол-во запросов сокращается до кол-ва ключей, а не равняется кол-ву ключей, помноженному на кол-во записей.
Спасибо за предложение, допишу в хуке, протестирую на количестве записей нормальном. Опыт подсказывает, что WHERE IN зачастую ужаснее выборки 1 записи по индексу
Если вы выбираете 1000 строк с 3—4 ключами в каждой — вам прийдется сделать 3—4 тысячи запросов.
* не дописал
Так вот.
Если вы выбираете 1000 строк с 3—4 ключами в каждой — вам прийдется сделать 3—4 тысячи запросов.
Какой бы не особо быстрый WHERE IN не был, он в любом случае будет быстрее.
Да и вообще, делать больше 5 (ну максимум 10) запросов в базу на страницу я считаю ужасным, за исключением редких, особо сложных случаев.
Так вот.
Если вы выбираете 1000 строк с 3—4 ключами в каждой — вам прийдется сделать 3—4 тысячи запросов.
Какой бы не особо быстрый WHERE IN не был, он в любом случае будет быстрее.
Да и вообще, делать больше 5 (ну максимум 10) запросов в базу на страницу я считаю ужасным, за исключением редких, особо сложных случаев.
Хм. Расскажите, где вы на одной странице выбираете 1000 записей. Я вот думаю о пагинации и не особо представляю, где должно быть 1000 записей
Ну 1000 это в качестве примера (хотя и такое случается, когда, например аггрегируешь френдленту, как вконтакте — фотографии, лайки, комментарии, это все собирается, группируется и т.п. — данных очень много).
Даже если 100 или 50 (что случается часто) — на каждую строку делать еще 3—4 запроса это кощунство.
Нет, тут уж каждому свое, но я люблю когда все работает быстро и мне выносит мозг, когда на генерацию страницы уходит по 60—100 запросов.
Даже если 100 или 50 (что случается часто) — на каждую строку делать еще 3—4 запроса это кощунство.
Нет, тут уж каждому свое, но я люблю когда все работает быстро и мне выносит мозг, когда на генерацию страницы уходит по 60—100 запросов.
количество запросов со словом «быстро» напрямую ведь не кореллирует, я надеюсь, вы это понимаете?
Но в общем вы дело говорите
Но в общем вы дело говорите
Кореляция не прямая, но есть.
Можно нагородить такой запрос, который будет медленнее 2—3 простых.
Но очень вряд ли вы сможете нагородить такой запрос, который будет медленнее 10 и более простых — накладные расходы просто перевесят. ну, у меня, по крайней мере, так никогда не получалось )))
Даже сложные запросами с кучей джойнов, юнионами, конкатенациями и прочими приблудами получаются быстрее.
Чем больше запросов — тем больше накладных расходов, они и пожирают время и ресурс.
Можно нагородить такой запрос, который будет медленнее 2—3 простых.
Но очень вряд ли вы сможете нагородить такой запрос, который будет медленнее 10 и более простых — накладные расходы просто перевесят. ну, у меня, по крайней мере, так никогда не получалось )))
Даже сложные запросами с кучей джойнов, юнионами, конкатенациями и прочими приблудами получаются быстрее.
Чем больше запросов — тем больше накладных расходов, они и пожирают время и ресурс.
Мне как-то пришлось смотреть стек выполнения запросов в Битриксе без кэширования – там так же, только еще страшнее, тянутся записи по айдишникам. 200-400-800 запросов на главную страницу бывает, но работают быстро, с кэшами так вообще отлично держат нагрузку.
Понимаете, тонкая настройка производительности нужна далеко не каждому проекту
Понимаете, тонкая настройка производительности нужна далеко не каждому проекту
Битрикс — это вообще клоака, которую я бы не стал рассматривать в качестве примера (по крайней мере положительного) =))
тонкая настройка производительности нужна далеко не каждому проекту, но это не значит, что их нужно растрачивать направо и налево не задумываясь
Тут спор, можно сказать, извечный) Кеширование решает, но я считаю, что это — «крайний этап оптимизации». Т.е. производительность на всех этапах должна быть высокой, а кеширование — это финальный штрих.
Ведь то же кеширование применимо отнюдь не всегда. Иногда данные нужно получать без задержек. И тут уже эти ваши 800 запросов на каждый клиент уложат сервер бд на раз-два, как туда зайдет несколько десятков человек.
Собственно, возможно, это мой фетиш.
Я не использую ORM вообще как раз потому что они жутко медленные. Я и тяжелые фреймворки, вроде симфони или зенда, не люблю. Делаю все на кодигнайтере, который обладает великолепным балансом функциональности, удобства и производительности.
Но все же с WHERE IN поиграйтесь — он очень сильно сэкономит ресурсы. А перебор по массивам в пхп — быстрый.
тонкая настройка производительности нужна далеко не каждому проекту, но это не значит, что их нужно растрачивать направо и налево не задумываясь
Тут спор, можно сказать, извечный) Кеширование решает, но я считаю, что это — «крайний этап оптимизации». Т.е. производительность на всех этапах должна быть высокой, а кеширование — это финальный штрих.
Ведь то же кеширование применимо отнюдь не всегда. Иногда данные нужно получать без задержек. И тут уже эти ваши 800 запросов на каждый клиент уложат сервер бд на раз-два, как туда зайдет несколько десятков человек.
Собственно, возможно, это мой фетиш.
Я не использую ORM вообще как раз потому что они жутко медленные. Я и тяжелые фреймворки, вроде симфони или зенда, не люблю. Делаю все на кодигнайтере, который обладает великолепным балансом функциональности, удобства и производительности.
Но все же с WHERE IN поиграйтесь — он очень сильно сэкономит ресурсы. А перебор по массивам в пхп — быстрый.
Так у вас просто никогда не было больших табличек :) Даже в оракле запрос по PK в таблицу с 1млрд строк выполняется мгновенно, а банальный count(*) уже чуть ли не минуту висит. Промахнулся с условием мимо индекса — сиди жди результата. Забавнее всего дебажить запросы, которые выполняются по 4-5 часов :)
packagist.org. Вводим в поиск orm и ещё раз спрашиваем себя — зачем оно надо?
И что вы этим хотели сказать? 3 страницы, для CI нет ничего сходу готового, и это ORM, я же писал – моя библиотека называться ORM никак не может. Это маппер максимум, а для 90% задач его достаточно
Для саморазвития. Не вариант? В велосипедах есть один, для меня по крайней мере, большой плюс: пока пишешь — глубже вникаешь. И это есть хорошо.
Тогда автору определенно стоит посмотреть как работает доктрина
Если бы вы читали пост, то увидели бы
И я еще раз повторяю, доктрайн – громадная, монструозная и именно ORM. Эта библиотека для тех, которые, как я, не хотят использовать полноценную ORM, но хочет подтягивания полей связанных записей.
Да, конечно, можно взять готовую ORM, повозиться с прикручиванием ее к CodeIgniter (либо она у вас есть в поставке, если вы пользуетесь другим фреймворком), написать описание классов модели и связей… Стоп. Опять написать.
И я еще раз повторяю, доктрайн – громадная, монструозная и именно ORM. Эта библиотека для тех, которые, как я, не хотят использовать полноценную ORM, но хочет подтягивания полей связанных записей.
А я не про орм писал, а про «большой плюс: пока пишешь — глубже вникаешь»
Doctrine вообще по другому принципу работает
Ну почему же, она тоже маппит данные на объекты, конечно помимо этого она «менеджит» сущности (да и еще много чего делает), но в основе идея одна. А если вы про то, что у вас метадата прямо из схемы читается — так это тоже доктрина умеет делать, только она не в рантайме это делает, и вместо этого генерирует модели для дальнейшего использования
Вот генерация моделей для меня лишняя, да и много чего еще лишнее, тяжелое и веселое. Да и подход там другой, маппятся поля на реальные объекты. А у меня просто объект данных собирается, т.к. Active Record в CI никакого отношения к паттерну Active Record и ORM не имеет
> Active Record в CI никакого отношения к паттерну Active Record и ORM не имеет
Лол :) Я ведь начинал с кодигнайтера когда-то. не понимаю что вас на нем удерживает) единственное для чего он хорош — это для обучения новичков основам MVC, фреймворков и всего такого…
А все эти «тяжеловестность» нивелируются удобством разработки. Более того, тот же симфони довольно немного кушает и по памяти и по процессору
Лол :) Я ведь начинал с кодигнайтера когда-то. не понимаю что вас на нем удерживает) единственное для чего он хорош — это для обучения новичков основам MVC, фреймворков и всего такого…
А все эти «тяжеловестность» нивелируются удобством разработки. Более того, тот же симфони довольно немного кушает и по памяти и по процессору
Что только люди не сделают, чтобы не использовать Yii (вместо Yii по желанию подставляем Symfony, RoR и т.д.) :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
HyperActive Record – недо-ORM на CodeIgniter