I really loved this talk (and my brain stayed in his place...) !
I have two related questions :
- By keeping track of some time-related data, wouldn't we un-normalize our model ? For example, by adding a "Start VT" column in an employee table, it could duplicate the hiring date already stored, in this or another table. It looks to me like a small step from duplicating or calculating data. Am I wrong ?
- How could your Santa or planets examples be stored in a DB, knowing that the Transaction time is set to current time when inserted ?
- I think you're referring to tracking the valid time for each column. The current theory assumes that the 'fact' is taken to be the entire row. In practice that means duplicating most of the values in the row any time a column changes. You could de-normalise things and store the columns in separate tables to track valid-time per column but that would massively increase the complexity of the schema.
- I'm not totally sure what you mean by this one. I think you may be confused by the nature of transaction time: it measure when we believe a fact to be true. This is completely different from valid time. It quite possible for us to discover something that has a valid time starting or existing entirely in the past or the future. The transaction time would still start now as we believe the fact to be true from now.
Feel free to send me a message on Twitter or through joind.in if you'd like to chat about this further. :)
Comments
Comments are closed.
I really loved this talk (and my brain stayed in his place...) !
I have two related questions :
- By keeping track of some time-related data, wouldn't we un-normalize our model ? For example, by adding a "Start VT" column in an employee table, it could duplicate the hiring date already stored, in this or another table. It looks to me like a small step from duplicating or calculating data. Am I wrong ?
- How could your Santa or planets examples be stored in a DB, knowing that the Transaction time is set to current time when inserted ?
Thanks a lot !
Jonathan
Hey Jonathan,
Thanks for the review! To answer your question:
- I think you're referring to tracking the valid time for each column. The current theory assumes that the 'fact' is taken to be the entire row. In practice that means duplicating most of the values in the row any time a column changes. You could de-normalise things and store the columns in separate tables to track valid-time per column but that would massively increase the complexity of the schema.
- I'm not totally sure what you mean by this one. I think you may be confused by the nature of transaction time: it measure when we believe a fact to be true. This is completely different from valid time. It quite possible for us to discover something that has a valid time starting or existing entirely in the past or the future. The transaction time would still start now as we believe the fact to be true from now.
Feel free to send me a message on Twitter or through joind.in if you'd like to chat about this further. :)