Data has a context, be it the time at which it was captured, or a currency or a language. When data is detached from this context, it becomes worthless.
The dimension of time is of paramount importance because without this 'temporal context', it is hard to achieve a baseline or determine trends. Organizational structures morph with alarming regularity, for example. You can, of course, represent an organizational hierarchy as a simple tree structure that maps the current organization, but what if you need to calculate revenues attributable to a particular department, over a time period when organizational changes were happening? Likewise, product prices fluctuate daily, and tax regimes change often. Storing currency values in Vietnamese Dongs would be fine until you need to report past trade in dollar values. How do you manage the past exchange-rate fluctuations?
Even language isn't necessarily as stable as you might expect. Your marketing people might be horrified to find that the Twitter keywords that measure market sentiment about your product are only significantly effective over a limited time-range, since the argot of social media changes quickly (for example, 'bad' or 'wicked' meaning 'good').
Data never used to be like this. Historically, accounting data was securely related to its time by being handwritten in indelible ink and accounting systems applied the rules, taxes and restrictions pertaining at the time. Entries could only be 'contra'd', rather than deleted, or superseded, and the double-entry system made it resistant to fraud. The ledgers were manufactured already numbered to make wholesale deletion obvious. The early computerized accounting systems maintained this 'never delete, only over-ride' rule.
Temporal tables in SQL Server 2016 are a godsend to the database designer because they've previously always been tiresome to implement. Richard Snodgrass's pioneering work with temporal databases was ingenious, but showed how scarily difficult it was to get temporal tables right with the existing SQL standard. Constraints can become a nightmare. Microsoft's implementation makes a lot of sense and it was a good approach to extend SQL to do it and to involve a history table. Although it is going to have an obvious primary use in accounting systems, it is likely to make a number of different commercial applications far easier.
If we can more easily provide point-in-time versions of results, this could usher in a much broader cultural change in the way we handle data. Paradoxically, it brings back the facility we had in a pre-computer age, where it was easy to determine the state of a ledger, or other records, accurately at any date. The next stage is to allow text blobs to use temporal tables by introducing versioning and differencing. That would be an interesting hybrid technology!
Phil Factor.
