Вполне резонно, честно не задумывался ибо не было повода.

А у тебя в форме одно поле?
Ведь при регистрации приходится проверять еще кучу условий и уникальность логина - не последняя. Так что ориентироваться на то - прошел запрос или нет, идеологически не верно. Во первых, он может не пройти и по другой причине, во вторых, перед запросом на внесение записи нужно все же убедиться в её валидности.

Ну, если требуется проверка исключительно по совпадению логина и/или мыла, то unique вполне оправдано.

А разве проверка на существование целым запросом не более ресурсоемкое и длительное телодвижение? mysql_errno() отдает код ошибки, в данном случае будет что-то похожее на значение 1062. Не вижу лишних телодвижений.

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

if ($Result = mysql_query("INSERT..."))
{
    echo "Вы успешно добавлены";
}
else
{
    echo (mysql_errno() == 1062) ? "Такой юзверь существует" : mysql_error();
}

Какие проблемы?

Мне просто интересно, а что же тут такого мудреного и сверх заковыристого, с кучей лишних телодвижений?

Обоим плюсики в карму за невозмутимость и дерзость.
waldicom - улыбнул за пример с реактором )))

Допустим в базе 10 000 записей, по способу num_rows - запрос обойдет полностью все 10 000 записей, и выберет нужную запись.
По логике, если под №2 будет запись с тем же именем, данный вариант будет обходить всю базу данных. Просто логически Unique дойдя до параметра 2 сразу должно будет выдать ошибку, а не проходить всю базу данных. Быстрее, значит лучше.
waldicom twin: если мы так раньше не делали, или не пробовали, может стоит разок попробовать (не обижайтесь, я не утверждаю!)? По крайней мере для меня - это новое, вчера перед сном узнал, что так делать можно.
linker: я в следующем своем проекте попробую твой код, который ты дал =)
twin: ну проверку на валидность проходит до обращений к базе данных, это уже совсем другое действие. Все равно скрипт оборвётся ещё до обращений, если проверку на валидность не пройдет. А ответ ошибки Линкер написал правильно.

Семён и другие эксперты: а Вы что думаете по поводу unique?

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

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

Про обход всех записей - учитесь правильно общаться с бд и она будет вам отвечать взаимностью:

select null from table where login ="$login" limit 1

Задача бд - выполнять запросы и возвращать ответы. Все mysql_errno() отличные от нуля - это ошибка работы приложения или базы, но никак не рутина. Например мой враппер для общения с бд все отличные от нуля ерроркоды складывает в лог для последующего анализа мной. Учить этот логгер разбирать где ошибка, а где ошибка-недоошибка не имеет никакого смысла.
Ещё аргумент: ваша mysql перестала справляться с поставленными задачами и вы переносите проект на другой движок баз данных. Запросы переписали, а вот перепишите ли этот анализ ошибок - очень маловероятно, особенно если переносом будет заниматься посторонний человек, который вашу уникальную логику просто не сможет и представить. Не пишите код так, чтобы пришло заниматься реверс-инжинирингом для понимания его работы.

twin
Сам посуди, нарушение уникальности - это ошибка? Ошибка и еще какая, как от нее избавиться? Никак ибо она нужна иначе не будет работать механизм уникальности. А теперь подумаем, может MySQL лучше знает про уникальности и с чем их едят? Да и возможность получать код ошибки тоже наверное не для просто так придумали.

То что, там у кого-то чего-то там отсылает для анализа в логи, это разве проблемы мускула или пхп? Нет.

По эту сторону мы, ученики программирования, по ту сторону - разработчики MySQL, которые ввели в свою программу специально unique. Это не оплошность, они сделали это специально, и в новых версиях данный код не устаревает, как бывает с ПХП, значит unique является важным элементом.
Все кроме Линкера пытаются сказать, что unique вообще не нужно, но ведь если бы это так было, давно бы уже unique стало "устаревшим", с другой стороны разработчики намеренно до сих пор не убрали его, значит видят в нём эфективность.
Тогда вопрос, для чего существует unique, и где его применить?

П.С. сегодня праздник, пойду отмечать =) А вот в ближайшие пару дней я знаю, чем займусь - докопаюсь до истины, узнаю всё про unique =)))

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

Nikitian: Спасибо за правильный пример обращения к базе.

waldicom и Twin Ну не придерайтесь к словам, сегодня же праздник =) Я имел ввиду, что в данной ситуации не нужно. Хотелось бы узнать реальные вещи, когда unique будет актуальным.

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

Вы же не спешите исправлять ошибки, когда

SELECT NULL FROM `users` WHERE `login` = 'vasya'

возвращает пустой результат? Это не ошибка запроса, это ошибка запрограммированной логики работы приложения, которая ничем не отличается от проверки empty(), isset(), is_null() и прочие.

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

twin
ON DUPLICATE KEY UPDATE или IGNORE не подходят для данной задачи.

define('ERROR__USEREXISTS', 1062);
...
if ($Result = mysql_query("INSERT..."))
{
    echo "Вы успешно добавлены";
}
else
{
    echo (mysql_errno() == ERROR__USEREXISTS) ? "Такой юзверь существует" : mysql_error();
}

@linker твой код прост и удобен, но если я так зделаю, то получу при следующем релизе прозьбу от людей которые обслуживают б.д исправить ошибку запроса к б.д.
А если я скажу им что это не какая не ошибка, то они будут все ровно дальше каждый раз говорить что это ошибка, так как она в логе записана. После 300 E-mail или одного разговора с начальником прийдется изменить код чтоб тебя оставили в покое те кому платят именно за то, чтоб они нас о ошибках в б.д. информировали .

SlavaFr
Так а подправить логи, чтоб эта ошибка не записывалась, разве нельзя?

SlavaFr
А почему же возврат удачной операции называть ошибкой? В моём понятии ошибка - неправильная работа или отсутствие работы в целом. В данной ситуации MySQL вернёт: невозможно добавить по той причине, что такой пользователь уже существует, но при этом выполняется поставленная задача.
Неудачная операция: ты отправляешь запрос серверу, а он молчит. Ты отправляешь запрос серверу, а он говорит, что ты хочешь всякий бред сделать, таких комманд даже не существует. А удачная операция: ты отправляешь запрос серверу - он даёт ответ: "добавили пользователя" или "не добавили пользователя, потому что такой существует уже".

Ошибка, потому что запрос не проходит.
Читаем мануал -

twin
В данном топике, речь идет о проверке уникальности, т.е. о конкретной задаче. И чем FALSE отличается от иного вида ошибки? Ну возвращала бы mysql_query() не FALSE, а код ошибки? Какие трудности?

Заказчики вдолбили мне в мозг на уровень автоматизма слово "унификация". Другими словами, если я делаю mysql_query(), то ожидаю получить результат запроса, а не false. False - это ошибка и её обрабатываем соответствующим образом без костылей вида "Ну если это был инсерт при регистрации, то смотрим в другом месте...".
С другой стороны, почему для проверки уникальности одного параметра надо использовать костыль с разбором кода ошибки, а для проверки уникальности нескольких параметров уже делать другой запрос и анализировать его ответ? Ни один вменяемый заказчик не примет приложение, которое при попытке записи чего-либо в базу будет говорить: "У вас что-то не уникальное: либо логин, либо емейл, либо телефон, либо ещё какая-то хрень... Разбирайтесь сами что у вас не уникально." Сегодня уникальным должен быть только логин, завтра появится телефон и емейл - переписывать логику? Золотое правило программистов: если что-то работает, то не трогай! Дописать можешь, но менять.... Это сейчас кажется, что ни на что не влияет, а в будущем окажется, что ничего не работает. Именно поэтому и не рекомендуется использовать глобальные переменные, где нужен синглтон.
linker
И не надо путать мягкое с солёным. IA-32 не ради ли обратной совместимости с огромным парком имеющегося оборудования до сих пор поддерживается? Есть же CISC и RISC, которые уже со времён ещё Pentium MMX, постепенно интегрируются в IA-32.
Вернёмся опять к PHP. Можно написать так:

if(!$fp=fopen('filename.txt','r')){
echo'Что-то не так';//Либо файла нет, либо директория закрыта для чтения, либо файл не доступен для чтения..
}

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

Всех с праздником! К сожалению, традицию поддержать не удалось - коньяк кончился ещё на выходных Только пыво.

Сейчас пока шёл на улицу, вспомнилась аналогия с Windows.
При операциях: копирование, вырезать, Windows вместо того чтобы проверить наличие доступного места на конечном диске и заблокировать его для использования, начинает сразу копировать, а в конце выдаёт ошибку.

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

mysql_query("INSERT IGNORE INTO....");
if(mysql_affected_rows() == 0)
    echo "Фигвам";

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

Я бы не стал торопиться с выводами о оптимизации. Дело в том, что это несколько иная задача.

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

Ошибаешься, причем жестоко.

Где меняется логика? Сначала хотим уникальность логина, ставим индекс, потому передумываем, хотим по мылу, убираем индекс и ставим на другое поле, что-то в логике кода поменялось? Нет, логика как была (есть юзверь/нет юзверя) так и осталась в неизменном виде.

Что мешает ajax'ом возвращать результат 0 или 1 - ошибка или успешно зарегистрирован соответственно или какие иные значения?

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

twin
В предварительной проверке, конечно такой метод не подходит, тут даже думать нечего. Логика проверки каптчи и прочие подобные проверки отфильтровывают возможные проблемы еще до какого-либо запроса. Причем здесь JS?

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

Я предпочитаю тот вариант, который наиболее подходит в том или ином случае.

Я все сказал.

Странно слышать это от человека, яростно пропогандирующего ООП, а особенно в части "многократное использование кода"

Прямо противоположное заявление.

Rivalryzerg