UPDATE considered harmful

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-...

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...).

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