5

With the creation of Temporal Tables in SQL Server 2016 (or similar technologies in other databases), would you consider Event Sourcing unnecessary?

Both are audit techniques, very similar (one deals with entities, the other with specialized DTOs), but Temporal tables are far easier to implement as they are ready right out of the box.

Questions are - are temporal tables good enough replacement for Event Sourcing and if not, what would be the advantages of one over the other?

1
  • 3
    Event sourcing and temporal tables don't quite solve the same problem. Event sourcing involves objects; temporal tables involve data records. Your question is more or less equivalent to the question "if object-oriented programming is done primarily with object instances, then why do we use table-based relational databases instead of object databases or graph databases?" May 16, 2017 at 19:27

1 Answer 1

6

No. Temporal tables are not a replacement for event sourcing. They are complementary technologies. Temporal tables simply make a copy of the data to another table before updating or deleting the current state. The temporal table includes time stamps so you can query with AS OF and other new temporal keywords. If you issue a normal query, you will only get the current state as though it were not a temporal table.

Event sourcing can be thought as a transaction log or a queue of deltas. The events must be translated into a model (e.g. object or table) before they are useful.

A temporal table would be more appropriate for keeping a change history on CRUD data. Such data often has set constraints like uniqueness that a relational table can address, but an event store cannot. For instance, a Product configuration (ID, SKU, names, price, keywords, ...) could be an appropriate entity to represent in a temporal table and be able to track over time.

Event sourcing is more appropriate for permanently recording facts that multiple observers may be interested in. The ordering process could be an appropriate thing to store as events. This generally has a defined beginning (order placed) and end (order delivered or canceled) and several things that happen in between (payment received, payment rejected, order shipped, etc). And several different groups want to know about these events to coordinate work: Fulfillment needs pick lists to pull the items from warehouse, Shipping needs weights and dimensions and packing lists to arrange trucks, Sales Support needs contact info for orders with problems, Marketing wants to know trends, etc. Each of these groups has their own goals for the data. So having a one-size-fits-all data model (one Order table to rule them all) often does not work. Instead each group can read the events and apply them to their own purpose-built model. A temporal table does not help to accomplish this scenario.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.