если переменная == нужное значение, то оставляем это значениефишка в том что у вас выражение в первой части (которое будет тру или фалс), и вы хотите чтобы пхп автоматически "угадывал" какой из сравниваемых аргументов вы хотите получить, например из выражения $a > $b... ну или еще интереснее если там функция с возвращаемым булевым значением...
select `id`
form `user`
where `pin` = :generated_pin
limit 1Такой вариант рабочий, до поры до времени.вот на это я попросил привести альтернативу хранению в мэни-ту-мэни. И чтобы не возникало разночтений, так как вы упомянули что зависит от количества, написал что записей МНОГО. Но внятного описания какой-то ни было иной структуры хранения все-таки не увидел.
А вопрос был вообще в другом, ну по крайней мере как я его понял.Видимо вы его не правильно поняли. Черным по белому:
как оптимальнее реализовать поисковую выдачу?Ответ - никак, так как критерий оптимальности в данном построении неприменим.
не будет же он все переписывать, перепарсивать и переделывать.Как мы видим - отмечен решением ответ с предложенной мной структурой, подозреваю что будет. Кроме того вполне возможно автор малоопытен, но вполне адекватен, и сначала спросил как лучше организовать, а затем взялся за заполнение. В итоге поменять структуру не составит труда.
Thundercat не дал ответ на вопрос автора. Он просто предложил свой вариант организации, причем вариант, который приходит наверно самый первый на ум любому, кто столкнется с такой задачей.Вот отсюда и поподробнее - альтернативные варианты организации плс.
Я получил 451 ошибку и чем мне это помогло?
Если все путем настроено, то почта уйдет.
Он просто предложил свой вариант организацииНе свой вариант, а так как это делается по классике, действительно хотелось бы услышать "не мой" - свежий прогрессивный новый вариант хранения. Прошу, маэстро!
Опять же смотря где это используется и какой вообще объем данных.Ну вот чтобы не быть голословным - на БОЛЬШИЕ объемы данных. То есть реально вот - миллионы записей на десятки миллионов тегов. Внимательно слушаю.
Ну седлали вы селект, а он вам вернул объект в котором уже есть такой пин? Придется дальше генерировать же...
Но получается в цикле 1000 пользователей я огромное количество раз стучусь в базуТак делать нельзя. Логично не генерировать пин и потом проверять ВСЕ значения в базе, а вытащить только то что действительно может совпадать со сгенерированным значением, и 1 или может даже 2 раза перегенерировать. Ну будет 3 запроса, но не 1000 блин! И все 1000 или 10000 вытаскивать и в цикле сравнивать - бред, как по памяти так и по производительности.
Во первых я сначала проверю, перед продом.а когда упадет буду думать что пошло не так. найс.
Во вторых буду проверять /var/log/mail.logуже лучше, но во первых очень далеко не везде доступны логи, во вторых вы это заметите очень не сразу. так что тоже не айс. проще сразу писать нормально.
Правильный почтовый агент, доставит письмо даже без этих ваших всяких паролейИли не доставит, или отвалится, или не примет параметр, не соответствующий RFC, или еще с десяток или, и вы получите в ответ от mail() (та-дааам!) очень информативный фалс... или тру...