This allows adding new rows which either are fully qualified or use some or all column defaults while only modifying the desired subset of columns when the key is already present.

REPLACE INTO fails in this respect -- once the row is deleted, only the values in the new definition will be populated, so you'd better have somehow managed to define everything you don't want unset/defaulted for existing rows, in which case you're basically reinserting the entire table anyway.

This could well be another source of the data loss @Tony happened upon.

The previous developer(s) were quite fond of the "REPLACE INTO" syntax; the company's web app was littered with it. Many problems plagued the system, the most common was the "random" loss of data.

As it turned out, the database has been in use for many years; some tables holding more than 1M records, as well as keyed with composites. Inevitably, someone would complain to the mother company's I.T. dept about the app being slow. Mother company's I.T. would just simply restart the MySQL instance in order to get performance back up. This occurred many times per day.

Of course, the sluggishness was due to the fact that the db engine was rebuilding the indexes for large tables. Restarting the server simply resulted in nightmarish situations.

Long story short: a good db programmer SHOULD understand the semantics of "REPLACE INTO" and carefully consider whether it is necessary.

One thing that was not mentioned in this article was the additional overhead of foreign-key relationships and how those tables are impacted.

Anyway I wouldn't go as far as to fear using wither REPLACE or ON DUPLICATE KEY. It's like copy_pasting the entire tabel for backup befroe doing a DELETE. You should have perfect understanding on how both work, and based on that decide whether you want to use them...

I know about the val1=VALUES(val1), val2=VALUES(val2), val3=VALUES(val3), val4=VALUES(val4); option, however this increases the size of the SQL dramatically. It's not uncommon for there to be tables with 100+ columns, updating all of those columns would require my application to generate SQL statements that are many times longer, which slows down the query generation, and increases the time it takes to parse the query on the other end. It's not necessarily extra 'typing', but it's just inefficient all the way around, especially when you need to update many rows at a time.

How is that any better? It's still a lot of extra typing.

INSERT INTO objects (val1, val2, val3, val4) VALUES (1, 2, 3, 4) ON DUPLICATE KEY UPDATE val1=VALUES(val1), val2=VALUES(val2), val3=VALUES(val3), val4=VALUES(val4);

http://dev.mysql.com/doc/refman/5.1/en/miscellaneous-functions.html#function_values