

UPDATE considered harmful - chrisdew
http://www.chrisdew.com/blog/2013/06/05/UPDATE-considered-harmful-event-sourcing-mysql/

======
dragonwriter
The process described here -- event sourcing -- is of somewhat limited utility
_alone_ ; as the article notes it is limited to relatively small data sets
(because, as commenters have noticed, you magnify the size of the data and the
cost of queries when you do this), but some of the key benefits (such as
avoiding issues with locking) mainly come into play with high frequency of
updates, and small data size, high-frequency-update applications aren't
necessarily all that common.

The article doesn't really address where Event Sourcing is most useful, which
is when it is used on the "write" side of a system with CQRS (Command-Query
Responsibility Segregation) architecture.

See (among a vast volume that has been written on the combination of these
techniques): [http://cqrs.wordpress.com/documents/cqrs-and-event-
sourcing-...](http://cqrs.wordpress.com/documents/cqrs-and-event-sourcing-
synergy/)

------
lazyjones
While this is an interesting method (packaged in a broad, bait-ish claim), I'd
like to see where the described benefits are actually worth the increased
complexity and difficulty: for situations with a few 10-100.000 inserts/day,
you will not run into locking issues and beyond that, the wasted disk space
will become noticeable to prohibitive, especially on cloud-hosted systems.
History and undo might be useful in some situations (not likely with password
changes as in the example though), debugging is probably better achieved with
rotated logs, not extra data in your database (which you might want to backup
regularly...).

~~~
chris_wot
Except for specialized applications, I just cannot see how this is a good
idea. As the table size grows, your indexes are potentially going to get
enormous. And as your tables grow larger, there are other issues also.

He uses mySQL, which I'm not as familiar with, but I know with a index
organized table in Oracle, or a table with a clustered index in SQL Server,
there might be a lot fragmentation going on and the table might need to be
reorganized.

In short: an interesting idea, but impractical in most cases.

------
estebank
This is just a Slowly Changing Dimension[1] of Type 4 (using a historical
table in addition to a working table).

I personally like Type 2 (having everything in the working table with an
attribute to mark the current and all previous versions) because of its
simplicity to implement and maintain. Type 3 (having a column per version and
attribute you want to store) always looked ugly to me, but it has its uses.

1: <http://en.wikipedia.org/wiki/Slowly_changing_dimension>

