- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
foreach($Articles as $art){
$id = $art['id'];
$count++;
if(isset($_GET['str'])){
$str = (int)$_GET['str'];
$mn = $number*($str-1)+1;
}else{
$str = 1;
$_GET['str'] = 1;
}
if($count == $mn){
$flag = true;
$k=5;
}
if($flag && $k!=0){
$k--;
$title = $art['title'];
$content = $art['content'];
$author = $art['author'];
$date = $art['date'];
printf("<h1>%s</h1><br /><h3 align='left'>%s</h3>%s <a href='index.php?id=articles&str=%s&nomer=%s'>Далее</a><hr /><br />",$title,$date, substr($content, 0,800),$nav, $id);
}
}
Follow us!
UPD. А нет, форыч же...
Да до тебя ему далеко :)
$countRows=mysql_result(mysql_query('SEL ECT count(`id`) FROM `table`', $db), 0);
Но хочу предостеречь, что mysql_result штука быстренькая, но хрупенькая. Обработки ошибок не предусматривает изначально.
- запрос одного поля (select count(*) from table)
- запрос одной записи (select f,i,o from table where id=100500)
- запрос массива записей (select id,name from table)
- исполнение запроса без результатов (delete from table)
В каждой из них должны быть все необходимые проверки, и при ошибке они или вбросят исключение или тупо завалят скрипт, записав ошибку (и, возможно, текст запроса) в лог.
Крайне желательно, при этом, оформить функции так, чтобы они принимали не тупо строку, а еще и переменное число параметров, которые функция будет передавать в bind_param.
(Т.к. конструирование запроса с подстановкой параметров прямо в строку неудобно и, при бездумном использовании, опасно).
Время выполнения скрипта включает в себя время компиляции...
Хорошо, давайте откажемся от модульности (это ж лишний файл читать!), от функций (о боже, парсить определение!), уберем все проверки (они же тормозят исполнение!). Может быть еще переменные называть однобуквенными именами, их же парсер быстрее разберет? Или давайте писать без пробелов и отступов. Парсеру ведь пробелы не нужны...
А вот, твою мать, лепить фреймворк для решения элементарной задачи, которая в одну строчку решается - такой бред только сишнику в голову придти мог.
Как работает интерпретатор, и, в частности PHPшный, я знаю. И кстати - "интерпретатора".
Сделать 4 функции, которые будут использоваться в 99% случаев, когда нужно сделать запрос к БД, твою мать, уже фреймворк?
Причем эти функции сократят, блять, объем кода. Улучшат его ебучую понятность. И, ахуеть, даже позволят перейти на другую СУБД, если запросы не слишком привязаны к текущей.
Писать при каждом запросе (а их в проекте всяко будет не менее 10) говнокод в духе mysql_result(mysql_query(...), 0) - такой бред только пхпшнику мог придти в голову.
//одна строчка кода
- запрос одной записи (select f,i,o from table where id=100500)
//одна строчка кода
- запрос массива записей (select id,name from table)
//две строчки кода и забивание памяти хернёй.
- исполнение запроса без результатов (delete from table)
//одна строчка кода
Не, я понимаю, конечно, что ООП - это ппц как круто, но до откровенного маразма не надо доходить. Вот BB код реплейсить - там да, функция, а, извините, инклюдить файл, грузить класс и инициировать здоровенный объект, чтобы использовать один его метод, состоящий из одной встроенной функции пхп - да колись оно копьём!
Где вы тут выкопали ООП?
> состоящий из одной встроенной функции пхп
Параметры запроса экранируете? Вот уже и не одна...
> //две строчки кода и забивание памяти хернёй.
А вот с этим согласен, но для мелких запросов это удобнее чем портянка из query/fetch/close.
2) Параметры запроса в запросе не экранируются. Все прилетающие снаружи данные обрабатываются ещё в индексе во первых строках. Ибо нех, но всё-равно надо. Ну а если вам внутренние данные экранировать приходится, то ёлы-палы, я хочу другой глобус.
3) А так у вы заменяете портянку while($res_list=mysql_fetch_assoc($res)) на портянку foreach($array_query as $res_list)
Нихрена не вижу разницы в читабельности, а вот память очень жалко.
А если эту строку надо как-то обработать (ну, к примеру, порезать из нее теги), то снимаем экраны и ставим заново?
> Ну а если вам внутренние данные экранировать приходится
Не приходится, есть bind_param.
Если соблюдать этот стиль везде, не забывать заэкранировать строку при получении данных из каких-то источников кроме параметров, и в sql запросах всегда заключать строки в двойные кавычки - ну согласен, работает и безопасно.
Оно, кстати, точно уж в разы быстрее.
1) Magic quotes also use the generic functionality provided by PHP's addslashes() function, which is not Unicode aware and still subject to SQL injection vulnerabilities in some multi-byte character encodings.
2) Это опция, включение которой не всегда возможно.
Мне этого достаточно. А вам?
2) А её не надо включать. Её надо отслеживать. Представьте во что у Вас данные превратятся если она включена, а вы сверху экранирование повесите.
Вот придумают спорных и, зачастую, неуправляемых со скрипта, опций на свою голову. А потом ПРЕВОЗМОГАЮТ их, тратя время, которое можно было бы потратить на что-то более полезное. Пхпшники как дети честное слово.
So much pathos
SELECT count(1) FROM `table`
Это, во-первых.
>Время выполнения скрипта включает в себя время компиляции.
Тут непонятно. Ты о абстрактном плане выполнения запроса, хотя сомневаюсь.
Наверное речь о времени конкатенации строки? Оно ничтожно.
Люблю пехепешников, которые c видом знатоков говорят о подобного рода оптимизациях.
>Вы плохо знаете работу интерпритатора
Дальше не читал.
И нефиг.
>SELECT count(1) FROM `table`
Закопайся сам, пока я лопату не нашёл, а то по частям закапываться будешь. Любое изменение структуры базы...
Урод, короче. Наверное и инсёрты у тебя без полей идут.
Давай, продолжай свою мысль.
>Урод, короче
Обосновывай.
... при переименовании поля id приведет к крашу вашего кода, и не затронет кода 3.14159265.
P.S. В другой теме разбирали, что count(1) count(id) и count(*) идентичны, если поле not null.
Это только уметь надо - так не каждый сможет
>В другой теме разбирали, что count(1) count(id) и count(*) идентичны, если поле not null.
А можно мне сцылочку. Пропустил.
Видимо о времени исполнения PHP скрипта в целом.
Тут дело вот в чем.
В хранимой процедуре запрос при первом вызове компилируется (разбирается SQL-сервером и создается план запроса).
А в некоторых БД (Огакл) даже императивный код процедуры, а не только запросы, может компилится в исполняемый код, который сохраняется в кеш и при вызове процедуры она сразу исполняется.
Сомневаюсь, что гражданин копал так глубоко.
http://govnokod.ru/10871#comment142244
А вчера в инете, прочетал чудную инфу - сейчас компилируется всё java, python, vb, haskell, javaScript компилируется даже php, даже SQL!
Кстати все эти интерполяции в виде "$key = $value" скорее всего в p-code превращаются в какой-нибудь concat($key, " = ", $value). А все что стоит за тегами <?php ?> превращается в echo.
Ну по крайней мере я бы так сделал ;)
Тест повторял несколько раз - результаты те же, с отклонением +-1мс.
Вывод - тип кавычек не влияет на производительность.
P.S. Сейчас придут пхпшники и начнут доказывать, что эксперимент проведен некорректно.
А результат несколько странный, ибо интерпритатар обязан просматривать содержимое литералов в двойных кавычках
The parser parses the stream of tokens passed to it from the lexer and generates an instruction set (or intermediate code) that runs on the Zend Engine. The Zend Engine is a virtual machine that takes assembly-style, three-address instruction code and executes it.
Да разница то, скорее всего есть, но она настолько ничтожна, по сравнению со временем старта интерпритатора, что мы ее не замечаем :)
P.S. А он и одинарные просматривает. Куда ж ему деться, надо же найти закрывающую кавычку.
> Да разница то, скорее всего есть, но она настолько ничтожна
Дык надо разрешающую способность бенчмарка увеличить
> Zend Engine
Ух ты ж, я не знал, что оно в core, а не extension.
Окай...
> В одном случае автомат ожидает апостроф, а в другом - кавычку и еще ряд символов.
Дело в том, что в одинарных кавычках он ожидает кавычку, бекслеш и конец строки (итого 3), а в двойных - кавычку, бекслеш, конец строки и доллар (итого 4). При любой реализации (ну кроме тупо трех ифов) разница должна быть невелика (или ее вообще не будет, как например при реализации через таблицы или switch).
По просьбам трудящихся был поставлен второй эксперимент. Использовалось PHP 5.3.10. Размер файла был увеличен до 150мегабайт. Файл состоит из миллиона строк следующего вида:
$name = "aaaaaaaaaaaaaaaa...aaaaa". Этого должно хватить, чтобы время парсинга превысило время загрузки и исполнения (которые нам не нужны).
Результаты 30 тестовых запусков: http://pastebin.com/0pYYpfF8 и график http://rghost.ru/38713458.view
P.S. Результат очень странный, пробовал заново - результат не поменялся. Порядок запуска влиять не должен - сначала запускал 30 раз сингл, потом 30 раз дабл.
Да и функции велосипедные, скорее всего, никакие писать не надо: PDO вроде как идёт в комплекте.
include();//это база, но мы её десять раз переписали
include();//на хабре утром сказали, что это модный фреймворк
include();//А это чуваки с пятого этажа писали, комменты в черепахе
$framework->$shabra($to->$chto->$pisali->$chuvaki->$s->$pyatogo->$etaja('Семнадцать'), true) or die 'Всё пропало, гипс снимают, клиент уезжает';
//Конец модуля
поэтому идеальный main модуль должен всегда состоять из
Хуже индусского кода может быть только код европейский, особенно голландцев или датчан. Это тоже объяснимо, у них источники вдохновения легализованы. Из точки А в точку Б никто никуда не едет, зато есть framework. В котором можно задать plug-in, который конфигурирует другой plug-in, который читает третий plug-in и посылает event четвертому, а тот уже знает, что делать. Через Inversion of Control, так интереснее. Я как-то цитировал одно европейское творчество, и, по-моему, это достойно повторения:
Before describing the configuration aspects of components (...), component types and implementations are described, since it is aspects of the component type that are configured by components – and the configurable aspects are defined by the component type.
И это только документация, а исполнение, поверьте моему горькому опыту, еще затейливее.
А от себя могу только в жаву послать. Это там однострочные методы крутяк неимоверный.
Я стараюсь не использовать библиотеку, если не знаю, как её реализовать собственными силами, т.е. если не понимаю, что и как она делает. Только если все существующие инструменты мне не подходят, я пишу вариант, удовлетворяющий лично мои потребности, и оформляю его в виде модуля с простым и понятным API. Недавно как раз обсуждали мой велик http://govnokod.ru/10175
Идеальный код находится где-то между этими двумя крайностями. Небольшие проекты ближе к линейным. Более сложные - ближе к тому что вы процитировали.
> Откройте исходник ipboard`а
Он же вроде платный?
Знаю я, что он платный, поспрашайте по знакомым. Наверняка кому-нибудь в наследство достался. Мне, например, достался. Тут где-то я выкладывал выдержки из этого продукта жизнедеятельности. Я его неделю ковырял, потом плюнул и за два дня написал новый.
В той статье есть здравое зерно. Не буду спорить.
>А от себя могу только в жаву послать.
Там кстати есть Spring JDBC где сделали то о чём говорил bormand:
>запрос одного поля (select count(*) from table)
queryForInt. если кол-во записей!=1 бросается православный эксепшон
>запрос массива записей (select id,name from table) - queryForList и объект маппера строки ResulSeta в сущность.
>запрос одной записи (select f,i,o from table where id=100500)
queryForObject. по сути то же что и первое, но получаем объект
>исполнение запроса без результатов (delete from table)
update. возвращается int - rows affected.
Какой-то супергерой. Который просто приходит и чинит всё. И ничего его не останавливает, будет писать с утюга.
Себя надо как-то уважать, например.
$h = $db->GetField( "COUNT(*)", $db_lots_archive, "WHERE uid='$p[from]'" );
$u = $db->GetField( "COUNT(*)", $db_lots_archive, "WHERE winner='$p[from]'" );
$y = $db->GetField( "COUNT(*)", $db_lots_archive, "WHERE uid='$p[to]'" );
$a = $db->GetField( "COUNT(*)", $db_lots_archive, "WHERE winner='$p[to]'" );
$s = $db->GetField( "COUNT(*)", $db_bn_bets, "WHERE uid='$p[from]'" );
$e = $db->GetField( "COUNT(*)", $db_bn_bets, "WHERE muid='$p[from]'" );
$b = $db->GetField( "COUNT(*)", $db_bn_bets, "WHERE uid='$p[to]'" );
$e1 = $db->GetField( "COUNT(*)", $db_bn_bets, "WHERE muid='$p[to]'" );
Это из одного уважЯемого интернет-аукциона.
Если нужно закрутить пяток шурупов - это быстрее сделать отверткой, что вы и делаете за несколько минут. Вася в это время раскуривает, как пользоваться шуруповертом, и уходит с работы намного позже вас.
На следующий день вам надо ввернуть 50 шурупов. Вы игнорируете шуруповерт, и продолжаете крутить их отверткой, руки устают, шурупы не дотягиваются до конца, но ведь шуруповерт надо заряжать, да еще и разбираться с ним... Ну его нахрен говорите вы, и продолжаете крутить...
Вася в это время качественно и быстро выполнил свою работу и ушел читать книжки и пить пиво...
На следующий день вы снова продолжаете крутить шурупы руками, на ходу объясняя Васе, что он дурак, и что шуруповерты не нужны, и от них только проблемы...
Пример отличный :) Продолжим его. Вы выкручиваете шуруп отверткой, радуетесь, что не нужно отодвигать шкаф, и ВНЕЗАПНО обнаруживаете, что плинтус все равно не снимается, т.к. мешает шкаф :) С матами вы отодвигаете шкаф и задумываетесь, почему бы не научиться проектировать...
P.S. И на всю жизнь клянётесь, что никогда не будете прикручивать саморезами приклеенные плинтуса.
Единообразие в проекте? Здравая мысль ;)
Ех, тяжела и неказиста жизнь простого программиста. Ажно пива захотелось.
В этих комментах Вы предложили оба варианта, потому что обычная отвёртка - это велосипед и говнокод. :)
P.S. Возможности (и сложность) современных фреймворков чаще всего избыточны, но эпоха велосипедиков неотвратимо проходит. Никто не говорит, что нужно ставить %название продукта сюда%, если нужна маленькая гостевая или брать фреймворк для одноразовой странички, нет.
include(противогаз);
include(лыжи);
include(камасутра);
include(антиграв);
Новый объект противогаз;
Новый объект лыжи;
Новый объект камасутра;
Новый объект антиграв;
антиграв->векторГравитации->инвертировать;
камасутра->позы->вверхНогами;
лыжи->одеть;
противогаз->одеть;
трахаться();
противогаз->надеть
fix
$this->одеть($Надежду);
Заметь, из нас всех только ты считаешь, что "мы пойдём своим путём" во всём. Спички для слабаков, для тех, кто не может без здоровенного мешка ништяков, с компасом, тушёнкой и навигатором. Фу таким быть! Мы, гриллсы, голыми руками убьём тюленя и сожрём сырым. Только программирование в машинных кодах, только хардкор. Это ли не стремление к ненужным самовозводимым проблемам?
P.S. Говорят, что неандертальцы по этой причине и вымерли.
> ради пустяковой задачи
> 4к онлайна
Не вяжутся как-то. При таком онлайне (вполне средний, вроде как) нужен нормальный архитектор, который знает, куда растить систему дальше, какой функционал потребуется и сколько это будет всё стоить. Плюс, вменяемые специалисты. И не факт, что написать эту систему с нуля будет быстрее (главное) и она будет надёжнее. У фреймворка же выносливость известна или сравнительно легко вычисляется.
(c) Исаак Ньютон
Ну почему, в споре часто выясняется что-то интересное.