Cutting Edge - Building an Historical CRUD RRS feed

  • General discussion

  • Create, Read, Update, Delete operations (CRUD) that were modeled on top of plain relational tables are now evolving into what we can generically refer to as historical CRUD, which is a CRUD codebase where the implementation manages to track down the entire list of changes.

    Read this article in the May issue of MSDN Magazine

    Monday, May 2, 2016 8:58 PM

All replies

  • Interesting article, showing how an event store can recreate a data store through time.  Although not mentioned, snapshots into data tables can allow normal SQL queries to be performed -- assuming a particular state (typically most recent).

    I am of particular interest with temporal tables coming in SQL Server 2016, as this solves many temporal related querying -- it should be noted that this is less powerful than what future uses can come from event stores that static schemas don't yield.  

    I do think a hybrid solution, given the resources, would be the best of both worlds:  use temporal tables for your static schema projections and event stores for analytic reviews.  Bonus points for integrating the R language with event sourcing.

    MSDN premium subscriber

    Friday, May 6, 2016 7:49 PM
  • I confess I don't know much about SQL Server 2016 except for some JSON capabilities coming up which could save you the burden of serializing yourself events or use a NoSQL or a pure event store for the purpose. Will find out more about temporal tables. Thanks for sharing your thoughts!
    Monday, May 9, 2016 9:05 PM
  • Although logically an append-only event stream, storing the data in a table (SQL or NoSQL / Azure table) with multiple entities in that same table does mean the physical implementation is not separate and therefore at some stage locking is going to be required.

    If you use an Azure AppendBlob per entity instance you can reduce the cross-instance coordination and achieve a higher level of parallelism. 

    In practice I prefer to have a logical interface between the event stream reader/writer and the underlying technology as what you eventually use as your storage technology should ideally be an implementation detail.  (e.g. http://www.codeproject.com/Articles/714742/CQRS-on-Windows-Azure-Event-Sourcing )

    Duncan Jones

    Wednesday, May 11, 2016 10:22 AM
  • In practice there is no need in separate storage for current snapshot. Instead of having initial state and replaying all changes to get current state you can have current state and revert changes when you need one of previous snapshots :)

    Friday, May 13, 2016 1:39 PM