Форум MySQL

Запрос примерно такой:

INSERT test SET t = 1 ON DUPLICATE KEY UPDATE t = t + 1

Мне нужно узнать ID вставленой или изменённой записи.
Без ON DUPLICATE KEY UPDATE я знаю как делать
mysql_insert_id() - его отдаёт, а вот если используется ON DUPLICATE KEY UPDATE
как быть?

Собственно, как обычно, определяйте последнее значение ключа t через функцию MAX()

SELECT MAX(t) FROM test;

Хм, как-то ...
1) Может параллельный запрос подменить значение
2) Лишний запрос к таблице

Ну, если иначе никак...

расскажите подробнее зачем вам id ?

Запрос INSERT ... ON DUPLICATE KEY UPDATE подразумевает изменение не первичного ключа (который, понятное дело, меняться не должен, потому что не должен меняться в принципе), а оставшихся полей записи. Среди них-то и можно выбрать поле, которым отмечать записи, подвергшиеся изменению посредством запроса.

>Запрос INSERT ... ON DUPLICATE KEY UPDATE подразумевает изменение не первичного ключа (который, понятное дело, меняться не должен, потому что не должен меняться в принципе),

Это мне непонятно. Допустим, таблица пуста. Выполняем запрос. Разве mysql_insert_id() Не вернёт нам свеженькое значение первичного ключа?

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

Я добавил поле
`

float_timestamp` = mktime(1)

И использую его почти вместо первичного ключа.
По его значению можно найти как обновлённую, так и вновь вставленную строку.
Получилось дополнительное поле в таблице - чисто для технических нужд.
Это нормальная практика?

>Это мне непонятно. Допустим, таблица пуста. Выполняем запрос. Разве mysql_insert_id() Не
>вернёт нам свеженькое значение первичного ключа?
Нет, вы же ключ назначили - механизм auto_increment даже не начинал работать, поэтому и возвращать функции mysql_insert_id() не чего. Так будет в любом случае, даже без ON DUPLICATE KEY UPDATE.

>Это нормальная практика?
Собственно почему нет, нормальная практика, если обновленные и вставленные строки важно различать, а другие механизмы, в силу причин, не годятся.

>float_timestamp` = mktime(1)
этой строки не понял.
>И использую его почти вместо первичного ключа.
Вы даже можете для обеспечения функциональности ON DUPLICATE KEY честно применять уникальный ключ, а не первичный. Как я понимаю первичность ключа - не есть требование.

>>float_timestamp` = mktime(1)
>этой строки не понял.

Это каждый раз я так заполняю одно из полей строки (вставляемой или модифицированной)
Потом нахожу эту строку по значению этого поля.

>>И использую его почти вместо первичного ключа.
>Вы даже можете для обеспечения функциональности ON DUPLICATE KEY честно применять уникальный ключ, а не первичный. Как я понимаю первичность ключа - не есть требование.

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

>>>float_timestamp` = mktime(1)
>>этой строки не понял.
>Это каждый раз я так заполняю одно из полей строки (вставляемой или модифицированной)

функции mktime(1) в стандартных я не нашел. Строка всё еще непонятна.

>Потом нахожу эту строку по значению этого поля.
>>>И использую его почти вместо первичного ключа.
>>Вы даже можете для обеспечения функциональности ON DUPLICATE KEY честно применять уникальный ключ, а не первичный. Как я понимаю первичность ключа - не есть требование.
>Не совсем понятно как на добиться чтобы в этом поле было действительно уникальное значение. Ни метка времени, ни случайное число уникальности не гарантируют

Так если Вы зададите в нем уникальное значение - никакого DUPLICATE не возникнет по определению.

>
>функции mktime(1) в стандартных я не нашел. Строка всё еще непонятна.
Да, разумеется, простите, я имел в виду microtime(1)

>Так если Вы зададите в нем уникальное значение - никакого DUPLICATE не возникнет по определению.
Так у меня не получается потому что в этой таблице есть поля, которые естественным образом определяют уникальную строку. По ним и создан уникальный индекс.
Мой запрос делает именно то, что нужно, добавляя или модифицируя запись.
Мой вопрос только в одном:
Как потом обратиться именно к той записи с которой работал запрос?

Предпочтительно было бы получить её первичный ключ.

Так создайте поле первичного ключа, но не формируйте его значение в запросе.
Все ключи Вы, правда, не получите - только первый.