dimabest
именно REPLACE

Хм… INSERT OR REPLACE… Не знал такого. Спасибо.
Хотя мне кажется, что у этого запроса не слишком явное поведение. Что будет, если у таблице два unique-поля и запрос перекрывает уникальность сразу двух объектов? Заменить оба сразу не получится? :-)
ИМХО, лучше эксцепшн.

dimabest
именно REPLACE

Факт, работает. Я повёлся на сообщение троля и проверил update. Спасибо, буду юзать.

ZZZ

dimabest
именно REPLACE

Что будет, если у таблице два unique-поля и запрос перекрывает уникальность сразу двух объектов? Заменить оба сразу не получится? :-)

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

По поводу твоего примера.
В sqlite запрос с replace работает так же как в MySQL - он сначала удаляет записи с конфликтным ключом(ключами), а затем вставляет запись из запроса.

Если в базе есть Петя Сидоров, и Вася Иванов с отдельными unique на имя и фамилию то при replace Пети Иванова - предыдущие 2 записи будут удалены, а Петя Иванов вставится. Можете использовать как фичу :-)

Если фич не надо используйте REPLACE + первичный ключ.

dimabest
В sqlite запрос с replace работает так же как в MySQL

Никогда не работал с MySQL (PostgreSQL – наше всё!) и поэтому просто не сталкивался.

dimabest
Если в базе есть Петя Сидоров, и Вася Иванов с отдельными unique на имя и фамилию то при replace Пети Иванова - предыдущие 2 записи будут удалены, а Петя Иванов вставится. Можете использовать как фичу :-)

Это не по Дзен, так как не очень очевидно. ИМХО, лучше таких вещей на практике не использовать.

alexx11
Я повёлся на сообщение троля и проверил update.

Троля? Знаешь что, мальчик, следи за словами. Я тоже не Бог и могу иногда ошибаться, хотя с базами данных работаю уже много лет. Всё.

ZZZ
Это не по Дзен, так как не очень очевидно. ИМХО, лучше таких вещей на практике не использовать.

Не могу с вами согласиться, коллега. Именно на практике то как раз и можно. Если, конечно, понимаешь зачем, почему и, самое главное, как (т.е. механизм).
Например, 3НФ оптимизирует размер БД, но вот со скоростью на больших объемах данных могут быть проблемы. Или вот для БД в режиме “только чтение” 3НФ тоже не обязательна. Особенно учитывая нынешнюю стоимость носителей информации.
Аналогично и с нестандартными фичами любой СУБД. Если фича вне стандарта, но помогает ускорить обработку запросов, то это один из самых что ни на есть практических приемов оптимизации. REPLACE в MySQL - одна из таких фич.

Lexander
Аналогично и с нестандартными фичами любой СУБД. Если фича вне стандарта, но помогает ускорить обработку запросов, то это один из самых что ни на есть практических приемов оптимизации. REPLACE в MySQL - одна из таких фич.

На самом деле я не много о другом… Про использование плюшек БД я полностью согласен, но с одной оговоркой – понять код должен человек, не знающий этих плюшек.
В данном случае, я, наверное, погорячился. :-)