У меня есть таблица вида: NOMER COD. Нужно проверить, если телефон уже есть в базе, то обновить COD, если нет в базе, то создать запить телефон - код. У меня получается что-то подобное сделать с помощью циклов в php, но лучше бы сделать это одним запросом или с помощью триггера.

Единственное что я придумал, и конечно же не работает:

И такой не работает

Это сообщение отредактировал(а) Parallelogram - 10.10.2015, 07:12

tel, разумеется, должэн обладать уникальным индэксом.

А если я создам еще 1 столбец, например 'id' с ним такой фокус пойдет? Пусто он будет уникальным идентификатором. Просто tel может повторяться.

P.s.: Не работает( Просто создает дубликат.

Это сообщение отредактировал(а) Parallelogram - 10.10.2015, 15:57

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

Ну, фигово тогда, чо. Сделай нормально пока не поздно.

зачем хранить несколько одинаковых записей?

Либо расскажи про задачу подробнее.
Например, почему телефон может повторяться и какие значения принимает код в таких случаях.


Этот ответ добавлен с нового Винграда - http://vingrad.com

В MySQL есть для этого специальное INSERT ... ON DUPLICATE KEY UPDATE ..., обеспечивающее полный контроль за процессом, и его более простой аналог REPLACE  - с минимальным функционалом.

При полном отсутствии UNIQUE это не поможэт ни капли.

Пусть добавит.  

Не надо вводить людей в заблуждение. REPLACE это НЕ аналог ON DUPLICATE KEY UPDATE. 
REPLACE тупо удаляет запись перед вставкой если конфликт по ключу, ON DUPLICATE KEY UPDATE обновляет указанные поля.
Чем чревато ?
Например есть поле TIMESTAMP с дефолтным значением CURRENT_TIMESTAMP. Это поле никто не изменяет никогда, но какая нибудь логика на него завязана. 
При REPLACE оно всегда будет NOW()...

Вот было бы странно, если бы они были полными аналогами, верно?

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

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

Просто я разок споткнулся когда заюзал АНАЛОГ. Поэтому и говорю что нельзя СОВЕТОВАТЬ что REPLACE это аналог ON DUPLICATE KEY UPDATE
Он работает ПО ДРУГОМУ. В моем случае было АБСОЛЮТНО по другому.
И если метод не работает ТАК ЖЕ то это НЕ аналог.
Кстати про триггеры. На ON DELETE в теории должны срабатывать на REPLACE, но не проверял.

Да никто с этим не спорит.


Вот этим и отличаются "аналог" и "эквивалент". Но зачастую критичен итог, а не путь его достижения. 
Тебе просто не повезло - итог получался не тот. 


Да. 
ON DUPLICATE KEY UPDATE - всегда срабатывает триггер ON INSERT, а при дублировании ещё и ON UPDATE. 
REPLACE - всегда срабатывает триггер ON INSERT, а при дублировании ещё и ON DELETE, после чего повторно срабатывает ON INSERT.