From CRUD to Event Sourcing
summary
Shows that SQL Server temporal tables (system-versioned tables, available since 2016) automatically keep a read-only history table with start/end timestamps, and that querying history requires the FOR SYSTEM_TIME clause. Demonstrates that Entity Framework identity map returns current snapshots for repeated keys so EF cannot enumerate historical rows without ADO.NET raw SQL. Builds a simple append-only match-scoring append-only event store plus replay and snapshot logic; it works but business events beyond CRUD require custom storage and read-model syncing.
AI-written summary · about
chapters (9)
- 0:00Start
- 13:01Aggregates
- 20:03Difference between Normal Classic Tables and Temporal Tables
- 22:51T Sequel Code To Create a Temporal Table
- 27:10Summary
- 31:50Create the Databases
- 35:19Querying the History Table
- 46:39Identity Map
- 57:00Log Method
related talks
43mEvent Sourcing dealing with an eventful past
30mDemystifying Event Sourcing: A Practical Approach to Modern Software Architecture
50mKeeping historical data in tables forever – mission (im)possible!
51mThings I Wish I knew Before I Started with Event Sourcing
51mThings I wish I knew before I started with event sourcing
52mEvent Sourcing – the what, why & how
52mEvent-driven vs event sourcing: what's really the difference?
10mEvent sourcing