2 компа... 1-й HTTP страничка... 2-й держит MP3 файлы для странички... Если пользователь уже есть то надо делать UPDATE, если нет - то INSET... Можно ли сделать это одним запросом? Если да - то как, если нет то то помогите пожалуйста оптимизировать запрос до минимума.... 2-й сервер имеет доступ только до UserID и UserIP....
replace не всегда можно. ведь он не обновит строку, а удалит её полностью, а потом вставит новую. если надо именно обновить старую, то лучше использовать INSERT ... ON DUPLICATE KEY UPDATE http://dev.mysql.com/doc/refman/5.0/en/insert-on-duplicate.html
Большое спасибо всем ответившим... Буду разбераться... Если появятся проблемы знаю к кому обращатся. :thankyou:
Ну вобще-то при наличии всёравно надо будет обновить, потому что вам нужно обновить дату последнего посещения, иначе у вас получиться что он больше не посещал. Идиальный вариант это таблица типа memory для online таблицы и делать PHP: <?php mysql_query('UPDATE online SET last_activity = NOW() WHERE user_id = '.(int)$someUserId, $database); if (mysql_affected_rows($database) == 0){ mysql_query('INSERT INTO online (filed1, field2, ... fieldN) VALUES(data1, data2, .... dataN)', $database); } ?> Некоторые делают вообще в один запрос используя REPLACE, но по мне он не очень хорош для этого, поскольку делает DELETE если такие данные уже есть а потом INSERT, что не хорошо для индексов.
во вселенной существуют не только форумы и не только таблицы посещений )) как НЕ обновлять запись если она уже есть? не хочется делать инсерт с ошибкой, т.к. все запросы у меня идут через свою функцию xquery а в ней есть die
можно обновлять какую-то глупость, например [sql]insert into `table` set id=1 on duplicate key update id=id[/sql]
зачем? мне надо ловить ошибки, а не прятать. и зачем писать запрос, который дает ошибку, если можно написать без нее?
у меня ОДНА функция для выполнения запроса. а в ней может быть и if ($this->curconnect!='') { $query=mysql_query($sql,$this->curconnect) or die(mysql_error()."<br /> ".$sql); и countquery(); и черти лысые. при правильном запросе die быть не может. если он есть - то нефиг работать дальше, целостность данных меня беспокоит больше. Для того чтобы НЕ использовать ее нужны веские аргументы, которых я не увидел. "а пох, наляпаем как попало"
еще как может. целостность данных тут никак не зависит от die. Вот это как раз в корне неверно. пох-наляпаем - это и есть использование die и выброса ошибок в выходной поток. Ошибки нужно обрабатывать, а не убивать скрипт. Для этого существует замечательная функция - mysql_errno().
Это в данном случае неважно, там die(mysql_error()) или if (!(mysql_query())) { filelog(mysql_error); filelog($sql); die; } или raiseError(mysql_error(),$sql); При ошибке запроса должно произойти что-то совсем ужасное, при этом дальнейшее исполнение надо прерывать. А вот примеры допустимых запросов с ошибками в студию.
Хотябы так - [sql] CREATE TABLE t1 ('i INT UNIQUE'); INSERT INTO t1 VALUES(1); [/sql] PHP: mysql_query("INSERT INTO t1 VALUES(1)"); Не надо ничего прерывать. Скрипт должен корректно обрабатывать такие ситуации...
НОРМАЛЬНАЯ работа должна прерываться. что там будет происходить - die или объезд - вторично. if not exists on duplicate key update или проверка до вставки.
Вот когда столкнешься с модульным программированием вспомнишь данный разговор. И неизвестно - выполнился данный запрос или нет. Лишняя нагрузка на сервер.
пишем, пишем. А вот вам, сэр, отвечать за достоверность инфы явно не приходилось. тогда проверять до. устраивать ошибки не выход.
да? Тогда ответь - что случится, если один модуль выполнит die => остальные не отработают? Правильно - полный крах всей системы. Отсуда вывод - такому программисту начальство премию не выдаст... Проверять - это лишний запрос в базу.
если один модуль выполнит die или что там мне будет угодно, то это означает: 1) форма read-only - что-то вообще страшное с базой, инфа не вывелась как надо. 2) форма ввода инфы. - 1) или - непредусморенная ошибка ввода данных, вводимые данные в принципе некорректны. гнать надо ссаными тряпками тех программистов, у которых модули в принципе в теории могут отдать неверную инфу как достоверную. Пусть пишут странички васям пупкиным. Как обрабатывать ошибки - вторично, в этом случае меня пока устраивает die, надо будет - поменяю В ОДНОЙ ФУНКЦИИ на другую обработку. Важно, что дальше не может выполняться последующий ввод или вывод на основании неверной инфы.