Comments 13
Спасибо за подборку! Пойду заменять все echo на die.
Добавил бы что появился Phalcon 2.0 RC1, релиз stable версии 17 апреля, но уже можно пощупать… http://phalconphp.com/ru/download
UFO just landed and posted this here
Отличный выпуск! Новые релизы ZF2 и Doctrine2 — вкусняшки.
Это какое-то извращение, выбрать Phalcon из-за скорости и использовать тормозной ORM, и жаловаться на то что этот ORM в их реализации делает 2 запроса к базе. Люди, не проще ли разобраться один раз в SQL и делать на нём всё что угодно, включая то что не позволит никакой ORM, и выиграть при этом в скорости выполнения. Люди стараются, придумывают ещё более быстрые вещи, такие как HandlerSocket и интерфейс memchached для mysql, а тут до сих пор используют ORM, который ещё и под каждый framework или cms свой. Изврат да и только.
У меня например есть SQL запрос на 30 строк с ROLLUP, который за несколько секунд строит отчёт по продажам за 10 лет с любыми сегментациями по месяцам, статусам, менеджерам, средним чекам и так далее. Хрен вы такое сделаете на ORM.
Объясните ещё, причём тут Microsoft и PHP? Или это просто некий канал, где всё обо всём?
У меня например есть SQL запрос на 30 строк с ROLLUP, который за несколько секунд строит отчёт по продажам за 10 лет с любыми сегментациями по месяцам, статусам, менеджерам, средним чекам и так далее. Хрен вы такое сделаете на ORM.
Объясните ещё, причём тут Microsoft и PHP? Или это просто некий канал, где всё обо всём?
Канал обо всем, но у Microsoft есть Azure, на котором можно хостить PHP-проекты azure.microsoft.com/en-us/develop/php
Как по мне так у Phalcon PHQL довольно удобный и быстрый… Да и вот после выхода версии 2.0 может что изменится… Да и никто же не заставляет пользоваться строго ORM — можно и свою обёртку под PDO написать
Чем PHQL лучше обычного SQL? Чем он хуже понятно — ещё раз съедает процессорное время. Эфимерное преимущество «любая СУБД» обычно не нужно в мире PHP, где базу выбирают один раз и навсегда (особенно если используются триггеры, хранимые процедуры и прочее).
p.s. это недостаток множества современных разработок. Что-то сделают, но не пишут — зачем это надо, чем это лучше.
p.s. это недостаток множества современных разработок. Что-то сделают, но не пишут — зачем это надо, чем это лучше.
Ну для новичков такие вот обертки над SQL'ом обязуют следовать каким-нибудь стандартам и не стрелять себе в ногу слишком часто.
Но как только задача начинает выходить из разряда обычных, эти PHQL, DQL, и т.д. начинают очень сильно портить все. К примеру взять PostgreSQL и его поле типа json, PHQL не даст работать с функциями PostgreSQL, и в то же время сама постгря не даст работать с полем как со строкой, в итоге получается что человек не может использовать все фичи того, что юзает.
К примеру есть запрос для постгри:
На DQL это будет:
никак(можно самому описать собственную функцию, описать ее конвертирование, но это займет over-много времени), такое сделать нельзя, только если указать поле типа text и вручную его из json и в json перегонять
Но как только задача начинает выходить из разряда обычных, эти PHQL, DQL, и т.д. начинают очень сильно портить все. К примеру взять PostgreSQL и его поле типа json, PHQL не даст работать с функциями PostgreSQL, и в то же время сама постгря не даст работать с полем как со строкой, в итоге получается что человек не может использовать все фичи того, что юзает.
К примеру есть запрос для постгри:
SELECT e.* FROM employee e, json_array_elements(e.roles) r WHERE r.value::text = :needRole
На DQL это будет:
никак(можно самому описать собственную функцию, описать ее конвертирование, но это займет over-много времени), такое сделать нельзя, только если указать поле типа text и вручную его из json и в json перегонять
Зачем? Затем, чтобы «абстрагироваться» и унифицировать использование. Чтобы из ORM генерировать поля для форм, из них формы их рендерить на страницах, и автоматически «валидировать» их. Это всё экономит человеко-часы. Ещё один сервер в стойку можно доставить хоть на следующий день, а написание отличного со всех сторон кода занимается месяцы, а то и годы. И вот когда все фичи реализованы, а баги исправлены — можно заниматься рефакторингом, и искать узкие места в производительности, и их оптимизировать. И опять же, оптимизация в этом случае чаще всего заключается не в простом $database->raw(«INSERT INTO ...»), а в оптимизации существующей ORM чтобы использовать её в следующих проектах, либо других модулях текущей системы.
PHP — под капотом — Слайды о том как устроен PHP.
О, автор тот самый человек, который не знает чем различаются
stack и queue =)
Поделитесь ссылкой или статьей, где он не различает?
В книге «Zend PHP 5 Certification Study Guide» есть глава «Arrays as Stacks, Queues and Sets», где написано:
Ясно что ошибка, но этот абзац уже несколько раз перекочевывал из издания в издание.
If you intend to use an array as a queue, you can add elements to the beginning and extract them from the end by using the array_unshift() and array_shift() functions:
<?php
$stack = array('qux', 'bar', 'baz');
$first_element = array_shift($stack);
var_dump($stack);
array_unshift($stack, 'foo');
var_dump($stack);
?>
Ясно что ошибка, но этот абзац уже несколько раз перекочевывал из издания в издание.
Sign up to leave a comment.
PHP-Дайджест № 60 – интересные новости, материалы и инструменты (30 марта – 13 апреля 2015)