TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

UPDATE considered harmful

4 点作者 chrisdew将近 12 年前

3 条评论

dragonwriter将近 12 年前
The process described here -- event sourcing -- is of somewhat limited utility <i>alone</i>; 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.<p>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.<p>See (among a vast volume that has been written on the combination of these techniques): <a href="http://cqrs.wordpress.com/documents/cqrs-and-event-sourcing-synergy/" rel="nofollow">http://cqrs.wordpress.com/documents/cqrs-and-event-sourcing-...</a>
lazyjones将近 12 年前
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...).
评论 #5825374 未加载
estebank将近 12 年前
This is just a Slowly Changing Dimension[1] of Type 4 (using a historical table in addition to a working table).<p>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.<p>1: <a href="http://en.wikipedia.org/wiki/Slowly_changing_dimension" rel="nofollow">http://en.wikipedia.org/wiki/Slowly_changing_dimension</a>