I can go concentrate on how best to use these.

Especially happy to know about REPLACE INTO. A “nice” way to do an UPSERT for my example cases. Now If I only knew when a source system deleted a row.

Assuming a table with 100 columns, 500,000 rows.
Test REPLACE INTO against INSERT … ON DUPLICATE UPDATE.

Assume all 500,000 rows get “modified” every time.

compare to TRUNCATE and LOAD DATA which solves the immediate problem of “what got deleted”.

http://dev.mysql.com/doc/refman/5.0/en/merge-storage-engine.html
and
http://dev.mysql.com/doc/refman/5.0/en/merge-table-problems.html

MySQL Forums for the MERGE talbe are at:
http://forums.mysql.com/list.php?93

In a nutshell, a MERGE table is really a set of pointers to similarly-schema’d MyISAM tables. So if you have the same table schema multiple times (ie, partition per day, so you have tables named 2007_04_27_Sales, 2007_04_26_Sales, etc) you’d use a MERGE table to link them all together and then you can run a query on the MERGE table and it will query all the tables that the MERGE table points to.

As for INSERT . . . ON DUPLICATE KEY UPDATE –

MySQL gives many ways to deal with INSERTs and unique/primary keys. If you do an INSERT and the primary key you are trying to insert is already in the table, MySQL will give an error. Ways to deal with this:

1) Try & catch errors in the application code.

2) Use INSERT IGNORE INTO . . . this will insert a new record if a record with the key does not exist. If it does exist, nothing happens.

3) Use REPLACE INTO . . .this will insert a new record if a record with the key does not exist. If a record does exist, MySQL will *delete* the record and then INSERT your record. This can cause problems when you just want to update part of a row, and not insert the whole row again. And it changes timestamps and auto-increment numbers, which may not be a desired result.

4) Use INSERT . . .ON DUPLICATE KEY UPDATE. The syntax is the regular INSERT statement, and at the end add ON DUPLICATE KEY UPDATE [expression]. For instance,

INSERT INTO tbl (id,name,thing) VALUES (154,’sheeri’,'book’) ON DUPLICATE KEY UPDATE thing=’book’;

and what makes it easier, if you have variables or whatever in your VALUES, you can actually set the update statement to say “just use the value I wanted to insert, OK?” as in the following:

INSERT INTO tbl (id,name,thing) VALUES (154,’sheeri’,'book’) ON DUPLICATE KEY UPDATE thing=VALUES(thing);

Manual page:
http://dev.mysql.com/doc/refman/5.0/en/insert-on-duplicate.html

Hope this helps!

These days we hear the “bust the silo” mantra, the “single version of the truth” mantra, and “the single data model.” All of which are bunk. Silos arose because of the division of labor. The myth of corporate culture pushed the idea that there is one culture, but really there is one dominant culture, the line culture, the culture of the strategic business unit, the culture of power. The division of labor cultures of the functional units are the silos. Of course, power wants to breach the silo, but to do so will force a generalist stance over the functional needs of the silos. The end result isn’t one version of the truth, but multiple versions of fiction.

Culture divides. Even within a single functional unit, paradigms divide on the basis of those who accept the paradigms that wash through a subject domain. In cost accounting you have traditional cost accounting, activity based accounting, and throughput accounting. Each of these paradigms have their adherants and their naysayers. Where a particular cost accounting department is on the issue depends on the manager, and the number of employees who believe in these to different degrees. This is a mess.

The usual practices in requirement elicitation is to say to the various functional units competing over any given requirement “after you settle this call me.” The conflict ultimately is resolved via line power and the requirement then becomes a source of requirements volitility as the political fight continues. Ultimately, it’s a matter of efficent implementation getting in the way of production. Production is always more expensive than implementation, so the efficency desire is pointed the wrong way.

A better mousetrap is really up to the mice, not the mousetrap makers.

See my bullet by bullet counter opinion on the original article on Strategic Board Blog

Thanks,
Dudu