Это неявная выборка. В случае изменеия структуры бд, например удаления колонки, вы узнаете об этом только в момент обработки, а не ранее на этапе запроса. Т.е. система уже не отвечает требованиям, заложенным ранее, а ошибка будет постфактум гдето дальше в коде.
В случае джойнов подобное вообщ нельзя писать от слова совсем так как будете иметь кашу из данных.
Рекомендую придерживаться принципа: явное лучше, чем не явное
ruboss
Вашим самым нагруженным сервисом будет бд. 1к rps запросов разделить это задача. Что бы это сделать нужно точно знать что за задачи будут выполнятся.
На LAMP стеке даже не думайте про то, что сервер будет один.
Ваша ошибка в том, что вы ожидаете конкретный ответ здесь, не давая полный список требований.(40 страниц это вполне ок). Очень рекомегдую нанять программиста (синьйора), для составления тз.
romy4
Пробовал. Собственно и в чем проблема?)) Нагруженный сервис как правило бд, а не система бизнес логики. 10к процессов спокойно могут сожрать цпу, но это не сравнимо с нагрузками на io жесткого диска, даже ssd.
oculos
Это дико медленная операция. Не дай вам бог в нагруженной крупной бд в 2 утра обнаружить тысячи 20 секундных запросов с этим. Для рэндома: выбираем список id их рэндомим на пхп и уже по полученному результату делаем полную выборку. Не стоит ушатывать бд потому что это просто.
dimon119
Switch это нетипизированное сравнение. За свою практику много раз сталкивался с неуместным использованием этой конструкции. Ее можно юзать, но очень осторожно.
regretful
Ужасная с точки зрения безопасности и тестирования orm. Магия на магии и магией поганяет. Для крупных проектов это может стать самоубийственной практикой.
Пропаганда статики на статике, это приводит к бесконтрольной связности проекта, с его развитием получается сттуация: для мелких правок необходимо сделать изменения в половине проекта.
Дока... б***ь обработка пользвательского ввод в моделях. Это путь в никуда. Я не спорю для мелких говнопроэктиков покатит, но не для чегото серьезного.
Посмотрите доктрину. Посмотрите symfony, silex.
Денис
Скажу честно, в моей практике do-while потребовался 1 или 2 раза. На счет создания переменных согласен, но фреймворк решает задачи инфраструктуры, а ваш проэкт - задачи вашего бизнеса. И для бизнеса обычно дешевле обходится быстро развиваемый и легко поддерживаемый код, чем сверх производительный, но при этом не саппортабельный.
У меня есть проектик ko-ko-ko/assert цель которого валидация входных аргументов простых типов в каждом методе внутри. он ужасен, dry вы***н во все щели, но эта штука очень производительная. Дык вот я молчу про создание переменной, даже присвоение недопустимо долго! Веду к тому, что это вспомпгательный проект ни как не решающий задачи бизнеса, но у него и нет бизнест тробований, только технические. Так же и фреймворк, он решает другие задачи.
Кодстайл и основные требований к коду - это не то место, где возможна демократия. PSR-5, который обсуждается публично не утвержден и тянется с августа 2013.
Было довольно забавное обсуждение: как трактовать var int? https://github.com/phpDocumentor/fig-standards/iss...
Мнения разделились на 2 лагеря, обсуждалось это дело с февраля по сентябрь. ~9 месяцев, Карл! В итоге PSR-5 не ставит требований по жесткому, или мягкому соответствию типов, указанных в докблоке.
В правилах написания кода не должно быть демократии (глупостей там тоже не должно быть). Для больших команд разработчиков, как показывает практика - чем жестче требования - тем лучше.
65536 Собственно и что?))
Я не являюсь core-dev-ом из Symfony Request. У них свои правила, более мягкие. У меня - более жесткие.
Вот вы просто прочитайте первую строку кода, что привели. Если вам в ней все понятно, прозрачно и очевидно - здорово, рад за вас.
Если же вытираете капельки крови из глаз - тогда пользуйтесь правилами, что я описал выше. Прочитать про них можете ...барабанная дробь... выше))
Например первая строка в случае жестких требований:
do {
// ...
$position = strpos($path, $baseUrl);
} while (($last > $index) && ($position > 0));
Зачем в оригинале идет сравнение и с false и с 0, я так и не вкурил.
65536
while (expr) предполагает выражение с булевым результатом. Если делать с ($row = ...) получаем неявное преобразование типов. Неявное преобразование лучше исключать от слова "совсем".
Arris > _опечатки_ вида (0 = $value).
любой, уважающий себя ide должен подсвечивать это как ошибку. А автор закоммитивший сие - в угол на гречку.
Но, так как == и != и присвоения в условиях запрещены - жесткой необходимости предохраняться от подобных ошибок кодстайлом не вижу.
Иван Тимофеевич
php-fpm - это реализация fast cgi интерфейса для интерпретатора.
mod_php - это модуль для apache, со встроенным интерпретатором.
Вещи это принципиально разные, но интерпретатор как правило используется один и тот же, подтягивается как динамическая библиотека.
Вячеслав Юрьевич я чп-шник, предоставляю услуги (поэтому самый точный ответ на вопрос где - в Украине), работаю с php 8-ой год.
Это не юношеский максимализм)) Это правила, написанные кровью и потом.
Так уж получается, что php - это язык быстрых решений, но что бы писать безопасный, тестируемый, расширяемый и производительный код приходится принимать жесткие меры.
Arris > строгому сравнению добавлю крайне полезный стиль сравнения...
Тут бабка на двое гадала))
1) ($value === 0) читается как: проверяемая переменная $value должна соответствовать 0.
2) (0 === $value) читается как: 0 должен соответствовать проверяемой переменной $value.
Мне больше по душе первый вариант, но явных проблем во втором я тоже не вижу. Посему как требование выставлять его не совсем стоит. Что так, что сяк - это ок.
