|
|
|
| Листая форум, я обнаружил такую закономерность: после каждого запроса анализируется результат его выполнения и выводится соответствующее сообщение.
Почему это необходимо?
Почему при исполнении других рнр-команд проверка не практикуется, а при обращении к базе она нужна. Что, база столь ненадежна? | |
|
|
|
|
|
|
|
для: Владимир55
(16.02.2009 в 11:37)
| | > Почему при исполнении других рнр-команд проверка не практикуется
При любых запросах куда-то (файлам, сокетам, БД и т.д.) проверка обычно практикуется.
Хотя, можно ничего и не проверять, php это позволяет. Но тогда как среагировать на внештатную ситуацию и корректно уведомить об этом пользователя и себя самого как разработчика. | |
|
|
|
|
|
|
|
для: Владимир55
(16.02.2009 в 11:37)
| | База-то как раз надёжна, "ненадёжно" соединение с базой, которое много от чего зависит.
Грубо говоря сервер с базой данных расположен где-нить в Австралии, вы успешно к нему подключились и отправили запрос... и в это время злой австралийский админ выключил рубильник. Как вы узнаете успешно ли произошла вставка или обновление? | |
|
|
|
|
|
|
|
для: Valick
(16.02.2009 в 11:47)
| | Как мне кахалось, сервер с базой входит в состав сервера как такового. Сюда же входит и интерпретатор рнр.
Что, у них разные "рубильники"? | |
|
|
|
|
|
|
|
для: Владимир55
(16.02.2009 в 11:55)
| | Сервер БД (MySQL) и HTTP сервер (Apache) это два разных сервера, и они могут (и как правило в масштабных приложениях, так оно и есть) находиться на разных компьютерах.
Так что один рубильник на два компьютера ещё ничего не значит. | |
|
|
|
|
|
|
|
для: Владимир55
(16.02.2009 в 11:55)
| | >Что, у них разные "рубильники"?
Более того, даже находясь на одном компьютере они между собой общаются так же, как если бы находились на разных. | |
|
|
|
|
|
|
|
для: Владимир55
(16.02.2009 в 11:37)
| | >Что, база столь ненадежна?
База надежна - не надежны люди, программисты. Если вы ошибаетесь в SQL-запросе, PHP об этом ничего не знает и не сообщает - вы этой ошибки можете не заметить, принять её за ошибку в бизнес-логике и долго искать проблему в других, совершенно рабочих блоках. Поэтому ситуацию следует обрабатывать всегда, даже если запрос очевидный и не содержит внешних данных. Это экономит в конечном итоге массу времени. | |
|
|
|
|
|
|
|
для: cheops
(16.02.2009 в 12:39)
| | Обрабатывать на стадиях отладки скрипта?
А из отлаженного кода обработку ошибок убирать? | |
|
|
|
|
|
|
|
для: Владимир55
(16.02.2009 в 13:13)
| | Теоретически да, однако, лучше этого не делать - дело в том, что ошибки все равно остаются в проекте, даже если приложение может работать годами без сбоев. Кроме того, современное приложение - слишком много от чего зависит. Допустим довели до ума вы свою систему статистики - стали переносить на другой сайт, а одну таблицу забыли - сообщение об ошибке вам это сразу сообщит, если такого сообщения нет - у вас просто не будет данных и вам придется долго и упорно рабираться почему на этом сервере работает, а на этом нет. Причем PHP будет переправлять ваше внимание на другие участки кода (он не в курсе проблем на стороне базы данных).
PS Собственно как поступать решайте сами, однако, с большой долей вероятности со временем вы вернетесь к тактике: запрос - обязательная обработка результата.
PPS Исключение составляют счетчики и анализирующие системы, в них если есть ошибка - пусть лучше они не работают, чем что-то выводят. Во всех остальных случаях - лучше ошибку обрабатывать - в конечном итоге это съэкономит время. У нас в студии - это требование на уровне закона - ни кому даже в голову не придет оставить не обработанный SQL-запрос. | |
|
|
|