Проверка корректности данных

[zerkms]

[...]тут был пост http://phpclub.ru/talk/showthread.php?s=&postid=855195#post855195[/...]

 

[Beavis]

после приведения типа (type cast)

 

[vovanium]

Alexandre

но часто она бывает слишком мелочная

я тоже когда-то так думал, и гордился тем что система при неправельном запросе пытается выдать страницу, потом обнаружил в поисковиках кучу левых страниц, а поисковые боты регулярно лазили по этим страницам, ведь для бота если url не выдает ошибку, значит его нужно кэшировать.

 

[Фанат]

Я очень извиняюсь, но вынес таки из предыдущего топика.
сказать по правде, мне кажется, что данный вопрос выеденного яйца не стоит.

 

[zerkms]

и то, и то - ошибка, но часто она бывает слишком мелочная, чтоб на нее обращать внимания

ололо. зачем делать недо-проверку? почему бы её не делать вообще.

что значить после кастования?

кастование - приведение типа.

ну и в чем нелогичность? ты же всеравно делаешь проверку, как минимум на то не нулевой ли id, в чем проблема, сделать проверку число это или нет?

как раз нет. я никогда не проверяю - нулевое число или нет. (int) и дальше передаём как есть в запрос без проверок

чтобы совсем тему исчерпать приведу свой реальный код:

class newsViewController extends simpleController
{
    protected function getView()
    {
        $newsMapper = $this->toolkit->getMapper('news', 'news');

        $id = $this->request->getInteger('id');
        $news = $newsMapper->searchByKey($id);

        if (empty($news)) {
            return $this->forward404($newsMapper);
        }

        $this->smarty->assign('news', $news);
        return $this->smarty->fetch('news/view.tpl');
    }
}

- у сайта далеко не один запрос их около десятка, и когда какой-нибудь бот начнет перебирать различные варианты строк вместо id, то в итоге получится сотни левых некэшированных запросов (в моем случае, по логам было видно, что перебирают боты, причем тупорылые, т.к. пытаются к разным урлам, добавлять одно и тоже)

ты глупый. поиск записи с id=0 "в сто раз" быстрее поиска по любому другому id (попадающему в диапазон). сложность поиска в случае с id=0 = O(1), в случае с ненулевым числом, и меньшим max значения ключа - O(log2 N).

- когда запросы коверкаются людьми, и в итоге на неправильный запрос выдается страница, то это страница довольно легко может попасть в индекс поисковикам (счетчики, контекстная реклама и т.п.), зачем плодить дубликаты.

кто мешает на неправильный запрос выдавать 404 ?

я в этой теме всё сказал. свои дальнейшие доводы можете оставить при себе.

 

[Фанат]

потом обнаружил в поисковиках кучу левых страниц, а поисковые боты регулярно лазили по этим страницам, ведь для бота если url не выдает ошибку, значит его нужно кэшировать.

Согласен с тем, что на не найдено надо выдавать 404. с запросом же, или без - на усмотрение программиста.

 

[vovanium]

ты глупый. поиск записи с id=0 "в сто раз"

Это ты глупый, отправка запроса mysql, парсинг его, пусть даже сверхбыстрое выполнение, возврат результатов, проверка результатов, значительно медленнее, чем сразу проверить значение, и не выполнение не только этого запроса, но и зачастую нескольких более сложных.
Или у тебя сайты исключительно выдают только новость по id и всё? У меня к примеру, к новости, выдаются еще новости и статьи по теме по теме, и т.п.

кто мешает на неправильный запрос выдавать 404

Ты вообще читать умеешь, я изначально говорил о том, что лучше выдавать 404, когда вводят левые параметры

 

[zerkms]

Или у тебя сайты исключительно выдают только новость по id и всё? У меня к примеру, к новости, выдаются еще новости и статьи по теме по теме, и т.п.

вот только до кода получения новостей и статей по теме дело не дойдёт. потому что новость не найдена.

Ты вообще читать умеешь, я изначально говорил о том, что лучше выдавать 404, когда вводят левые параметры

молодец, что говорил. я и не отрицаю, что говорил. мою точку зрения я изложил уже давно: если проверять, то проверять полностью и нормально. !$id это шиза, приводящая к рассмотрению частных случаев в коде и не решающая озвученную проблему, только запутывающая код.

Это ты глупый, отправка запроса mysql, парсинг его, пусть даже сверхбыстрое выполнение, возврат результатов, проверка результатов, значительно медленнее, чем сразу проверить значение, и не выполнение не только этого запроса, но и зачастую нескольких более сложных.

как только конкретно этот кусок кода станет тормозить систему - он и должен быть рассмотрен как кандидат на оптимизацию. до этого момента - не нужно усложнять себе же жизнь, подставляя подобные "подпорки-оптимизацеи".

 

[vovanium]

zerkms

!$id это шиза,

Ты похоже просто не того зацитировал у меня с тобой по этому вопросу, мнения совпадают.

подставляя подобные "подпорки-оптимизацеи".

Так оно и тормозило, так как, как я уже писал выше подобной хренью занимались не вручную. А поскольку на сайте было около 60 тысяч новостей и немного меньше статей, то намного быстрее сделать проверку параметров и выдать 404, чем гонять мускуль зря, тем более, что ботов контент сайта врядли интересовал.
*****

теоретически, правда. на практике мне настолько вылизывать лень.

Ну это главное чтобы в привычку вошло, первым делом проверил входные параметры на соответствие ожидаемым, если всё ок, то можно дальше выполнять всё остальное.

 

[Фанат]

да, но к поисковикам-то эта проверка отношения не имеет.

 

[zerkms]

А поскольку на сайте было около 60 тысяч новостей

на самом деле число новостей не влияет на производительность конкретно этого запроса.

ps: глупый какой-то топик. давайте закроем, может?

 

[Фанат]

закрыть такой топик просто. всего лишь перестать в него писать

 

[vovanium]

zerkms

на самом деле число новостей не влияет на производительность конкретно этого запроса.

Ты явно перетрудился, или читаешь как-то тему по диагонали. Где в теме написано что обсуждается конкретно запрос выборки новости по id?
Я пишу о реальной задаче, и выборка новостей по теме (при том что у каждой новости несколько тем), уже значительно отличается по сложности, от выбора по id. Но этот запрос выполнять совсем не нужно, если мы изначально увидели, что подставлены левые данные.