5 ms·

UPDATE considered harmful

4 points by chrisdew 13y ago

lazyjones 13y ago
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 13y ago
  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.
dragonwriter 13y ago
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-synergy/ http://cqrs.wordpress.com/documents/cqrs-and-event-sourcing-...
estebank 13y ago
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 http://en.wikipedia.org/wiki/Slowly_changing_dimension

4 points by chrisdew 13y ago

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 13y ago
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.

dragonwriter 13y ago

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-synergy/ http://cqrs.wordpress.com/documents/cqrs-and-event-sourcing-...

estebank 13y ago

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 http://en.wikipedia.org/wiki/Slowly_changing_dimension