Форум PHP

Суть такая, что нужно определить, имеется ли в таблице `users` некая запись "code", хотя бы одна. При чём результат настолько важен, что всё будет очень плохо, если данный поиск сработает недостаточно эффективно. То есть, если такой записи нет, то всё хорошо и можно «идти» дальше по коду, совершать следующие действия, вычисления и прочее. Если же такая запись есть, или была хоть малейшая ошибка, которую могла выдать MySQL (например, при неправильном указании поля в запросе или поиска не конкретного значения "code", а пустого "", нечаянно, конечно, и так далее), то нужно остановить код немедленно с выводом ошибки.

Код сейчас:

<?php unset ( $mysql_query ); if ( ! $mysql_query = mysql_query ( ' SELECT `id` FROM `users` WHERE `code` = "'.processingMySQL ( $_POST [ 'code' ] ).'" LIMIT 1 ' ) ) {     $_SESSION [ 'error' ] = '1630654';     header ( 'location: '.referer );     exit; } unset ( $mysql_num_rows ); if ( ! $mysql_num_rows = mysql_num_rows ( $mysql_query ) ) {     $_SESSION [ 'error' ] = '4310872';     header ( 'location: '.referer );     exit; } if ( $mysql_num_rows >= 1 ) {     $_SESSION [ 'error' ] = '*Очень важная ошибка*';     header ( 'location: '.referer );     exit; } ?>

Как изменить код для лучшей эффективной работы?

Вот сам сейчас решил ещё один вариант придумать:

<?php if ( mysql_num_rows ( mysql_query ( ' SELECT `id` FROM `users` WHERE `code` = "'.processingMySQL ( $_POST [ 'code' ] ).'" LIMIT 1 ' ) ) <= 0 ) {     // next... } else {     $_SESSION [ 'error' ] = '*Очень важная ошибка*';     header ( 'location: '.referer );     exit; } ?>

Здесь я иду дальше по коду, только если один единственный верный вариант получится >= 1 (то есть, реально оставить комментарий // next... в пустых скобках { }), а для всех остальных вариантов ошибка.

Или это как-то не комильфо?

Ошибка запроса при неправильном указании поля - по вине клиента? Это нонсенс.
Запросы с пустыми параметрами - это не смертельно, а запрос впустую, но предотвратить такое вполне под силу разработчику.
В остальном - есть соответствие, будет результат, нет соответствия, результат будет нулевой.

И от чего такая паника?

Паника по двум пунктам.

Пункт первый: не дай Бог в таблице появятся две записи с одинаковым значением `code`.

Второй: в первом примере код считаю нагроможденным, во втором — просто тупым.

Паники вообще быть не должно, как и не должно быть важных и не важных ошибок - все ошибки программные, это важные ошибки. Не может быть в запросе поля несуществующего, такие ошибки могут быть только на этапе отладки.
А не соответствие параметра условию, это не ошибка, это просто не выполнение условия, и обрубать исполнение кода по этому случаю, это как минимум не вежливо по отношению к пользователю.
В SQL существуют механизмы позволяющие "не дать Богу" записать дубликат в поле, да и положительный результат проверки на наличие, это никак не повод для паники.

Я дотошный. Бываю чересчур.

Вообщем, пока остановился на варианте таком:

1) Делаю запрос:

SELECT COUNT(*)

2) Если запрос не выдал явной ошибки, то идём дальше:

if SELECT !== ( boolean ) FALSE

3) Если COUNT(*) больше 0, то... (если требуется проверить на наличие), если COUNT(*) меньше 1, то... (если требуется проверить на отсутствие):

if ( [ COUNT(*) ] > 0 ) ...

if ( [ COUNT(*) ] < 1 ) ...

if SELECT !== ( boolean ) FALSE - это пустое занятие

SELECT COUNT(*) и COUNT(*) (используйте псевдномы, если уж хотите обратиться к результату) > 0 < 1? тоже пустое, ибо по условию не должно быть дубликатов, а значит вариант может быть только один - COUNT(*) || 0 || 1, то есть есть или нет.

Если вы пишите приложение, то определитесь с выводом ошибок в запросах. Негоже их разбрасывать по всему приложению. Есть функция, метод который выполняет запросы и возвращает результат в случае успешного выполнения, либо выводит ошибку. Следовательно, где-то:

mysql_fetch_row('SELECT 1 FROM tst WHERE var="test"') вернет булево значение false, в случае отсутствия значения, в противном случае будет возвращен ресурс (истина, и приводить к булеву типу для проверки этого, совсем не обязательно). Зачем для этого проверять больше нуля, меньше нуля, если важно знать только наличие.

В случае ошибки в запросе до этого дело дойти не должно - должна обрабатываться ошибка.

Если при запросе произошла ошибка, то и возвращается false, почему !== ( boolean) да еще и для FALSE, это глупость. Описание же ошибки можно получить, выполнив mysql_error().

Обычно, я использую один из двух вариантов построения кода при осуществлении проверки.

Пример 1:

<?php if ( *первое условие* ) {     if ( *второе условие* )     {         if ( *третье условие* )         {             // Ура! Можно выполнять требуемое действие.         }         else         {             // Error 3.         }     }     else     {         // Error 2.     } } else {     // Error 1. } ?>

Пример 2:

<?php if ( ! *первое условие* ) {     // Error 1. } if ( ! *второе условие* ) {     // Error 2. } if ( ! *третье условие* ) {     // Error 3. } // Ура! Можно выполнять требуемое действие. ?>

Я стараюсь писать код как в последнем примере, потому что, согласитесь, он более «красноречив» и краток.

Тем более ещё и более сократить можно, если условия простые (пример 3):

<?php if (     ! *первое условие*     || ! *второе условие*     || ! *третье условие* )     // Error. } // Ура! Можно выполнять требуемое действие. ?>

Проблема в том, что иногда ошибкой является не FALSE (if ( ! ... )) значение, а TRUE (if ( ... )). В этих TRUE-проверках TRUE-значение выдаётся только в том случае, если выполнено много условий:
1) Корректный код запроса.
Да, как Вы сказали, эти ошибки должны исправляться ещё на этапе отладки, но нужно быть готовым ко всему.
2) Наличие подключения к БД, наличие нужной таблицы и наличие полей, что названы в запросе.
Поля могут быть переименованы в будущем, при какой-нибудь реконструкции программы. И может быть такой случай, что в таблице поле переименовали, а в коде в одной строчке забыли.
3) И наконец, найденное значение, которое, в случае присутствия в таблице, и является ошибкой для кода.

То есть, если ошибка (FALSE) произошла из-за первого или второго пунктов, то скрипт не выведет ошибки (для скрипта ошибка-то, когда TRUE), а посчитает, что её не было и продолжит выполнение кода.

Вот мне и интересно, можно ли написать меньше кода, чем в самом первом сообщение этой темы, мною написанном.

Поля не могут быть никак переименованы бесконтрольно со стороны разработчика, иначе бросайте писать код и занимайтесь другим.

Из остального сказанного ничего не понятно - вы сами суть сказанного понимаете?

<?php
if (
! *первое условие*
|| ! *второе условие*
|| ! *третье условие*
)

А если условий 30 и того более? Кроме "красноречия" более ничего.

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

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

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

На форуме только Вы один?

А с чего вы решили, или я не подхожу под вашу "концепцию"? Ну тогда ждите собеседника-единомышленника.

Да не-е-ет ) Просто, как Вы не поняли моих мыслей, так и я не разобрался с Вашими.

В самом первом посте я предложил код и спросил, как другие смогут его написать по-другому, лучше, на их взгляд. Ни одного примера я так и не увидел. Примера, а не суждения.

Да не-е-ет ) Просто, как Вы не поняли моих мыслей, так и я не разобрался с Вашими.

В самом первом посте я предложил код и спросил, как другие смогут его написать по-другому, лучше, на их взгляд. Ни одного примера я так и не увидел. Примера, а не суждения.

А что обсуждать, если

if SELECT !== ( boolean ) FALSE - это действительно глупость, ибо FALSE это булев тип был "отроду", и применять к нему приведение к boolean типу, это для чего, чтобы еще более "булеанистей" стало?

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

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

Первый код посмотрите. Там нет никаких ( boolean ) FALSE, и ( boolean ) FALSE я нигде не предлагал. Это пунктик о том, что Вы действительно совсем меня не поняли. Говорите «исправьте», когда исправлять нет чего (предлагаете исправить ошибки, которые Вы увидели из-за того, что вообще не понимаете моих мыслей).

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

А это значит мои фантазии?

Да не обидными слова мои воспримутся.

Мне не пять лет, чтобы обижаться не понятно по какому поводу.

Все что вы писали, я читал, и если вас интересует рациональность, насколько я понял, то по всему вами писанному я и ответил - к рациональности это отношения не имеет.

И по пунктам некоторым писал комментарий, зачем же их еще раз повторять.

>Раз идею не поняли (расписанную в нескольких сообщениях разными словами)

И в чем тут идея? Это стандартный шаблонный подход, и придуман предшественниками вашими, далеко до того, как вы решили заняться этим.

Так чего вы хотите? Оценить - моя оценка плохо, если рассматривать как бы лучше. Или чего надо?

Я посмотрел, откуда Вы взяли if SELECT !== ( boolean ) FALSE. У меня такого в коде нет и не было. Это я для объяснения указал, то есть это не реальный кусок кода. Художественная подача, если хотите.

Хотя, я бы всё таки на месте администраторов форума почистил бы всю тему от моих и Ваших сообщений, начиная с. Ибо никакой нагрузки полезной в этой теме они не принесли: ни мои, ни Ваши сообщения. Попросту представляют из себя флуд.

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

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

Но то, что программирование тоже работа в чем-то творческая, это бесспорно, вот и включайте творчество.

Даже создавая сайт в одну страницу, вы создаете приложение. Пока оно на сервере и не разу запрашивалось, это мертвый набор символов. Но стоит ему попасть на клиента, вот тут оно оживет, да если еще взаимодействует с сервером...

А приложение, это концепция, прежде всего, и этой концепции должен быть подчинен не только серверный код, но и клиентский, html и css этого приложения, а концепция как раз и отвечает - разумны и нужны ли вообще в конкретном месте if с кучей выражений. А вы одной такой конструкцией своей хотите подметить целую концепцию и сделать ее универсальной. То есть, если все ваши доводы прочесть, то получается ровно это.

Я вижу только одно — много полемики и ни единого! примера, как было бы лучше. Вы простите меня, но я ценю оценку людей, когда они сами могут что-то показать.

Примера чего, таковой концепции?
Это слишком много примеров нужно, да и не нужны они, на стадии обдумывания приложения до конкретных IF еще ох как далеко. О чем надо в это время думать, я уже писал.

Интересуют примеры конкретные, были и такие, писал их и в этом разделе форума, и в JavaScript разделе, надо, найдете. А я уже не хочу искать, и повторяться совсем не охота.

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

Нельзя всего этого описать двумя тремя примерами, а то что вы не хотите думать в этом направлении, еще не говорит о том, что я не понимаю о чем говорю. А что вы там цените, для меня это не имеет значения.

Я уже восьмой год пишу свою систему. Уж поверьте, глобальное от локального давно отделил. Вот только нет предела совершенству. Поэтому переписываю старые алгоритмы с нуля по нескольку раз, и не от того, что они были плохи (они работали и ни разу не давали сбоя). Просто со временем я понимаю, что что-то старое можно сделать ещё, хотя бы чуточку, лучше, и делаю. В этот раз один из пунктов решил повесить на всеобщее обозрение, на этот форум, сюда. Уже вижу, что зря, толку от этого ноль, то есть FALSE. И закончили (с Вами) на этом, а то совсем расфлудились.

Даже и не знаю как уж вам и ответить.

Да пожалуйста, обсуждайте, вот только что? Как лучше будет записать несколько выражений условия - в строку или в столбик?

Еще раз - как бы вы не писали, в любом случае при большом числе таковых условий это будет совсем не рационально.
Ну подойдите в к этому вопросу с другой стороны - не А или Б или В или .... и подобное, а если хотя бы одно из условий не выполняется, то и нет ни А или Б или В или и ничего подобного.

Предположим, что у нас есть обработчик данных пришедших извне, при этом этот обработчик проверяет все данные, откуда бы они не пришли. Он не просто проверяет данные, но и сообщает пользователю о несоответствии данных.
При этом, как я говорил ранее, это не что-то притиснутое к какой либо конкретной форме, а для другой будет нечто иное, этот обработчик, скажем так, ведет диалог с пользователем по ранее определенным соглашениям, чем являются и области куда выводятся сообщения, и вид этих сообщений, и реакция их на действия пользователя.
То есть, клиентская часть, вся ее составляющая, и серверная часть, это единое целое.
Этому целому подчинены и html-код всех форм, и их стилей, и необходимый набор клиентских сценариев.
Серверный сценарий получает на входе ссылку на источник, то есть форму, данные которой он на текущий момент проверяет, а также набор условий по данным этой формы.

Подобную конструкцию, как пример основанный на наборах, который можно подключать в зависимости от типа данных или дополнительных условий проверки, я уже приводил здесь. Вы думаете это кому-то надо? Обычно предпочитают или "а работает и ладно", или "на уровне своего понимания". Вот так и у вас - вы зациклились на простой конструкции, не понятно чего хотите тут услышать о ней, но если речь идет не о конкретной единичной задаче, то я вам уже ответил - это громоздко, плохо, штучно.

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

1) пришли данные, отдали их проверять:
2) проверка не вернула ошибок, значит занимаемся основной работой, пишем данные, обновляем данные, кастрируем данные и все что требуется, в общем рутина, что и есть главное и основное из нагрузок на приложение.

Все, больше мне сказать нечего. А уж как вы будете поступать, это ваше личное дело.