How to design a database for non-time invariant data I am looking at designing a database where entries will probably not be time-invariant. For example, it contain entries of a customer company. The problem with a customer company is that many things can happen to it. The company can split, merge, move, go bankrupt, be bought, buy another company and so on. If I want to track interaction with this company over time, how should I design the database to be robust against all these things? I will also most probably have people in the database. These are also volatile - they resign, change job and so on.

So what is the best practice for working with non-time invariant data in a relational database? Or should I use some other database scheme?
It sounds like a problem easily solved by placing key tables in version normal form (VNF). This is actually just a flavor of 2nf but done in a way that provides the ability to query current data and past data using the same query.

A datetime parameter is used to provide the distinction. When the value is set to NOW, the current data is returned. When the value is set to a specific datetime value in the past, the data that was current at that date and time is returned.

A brief discussion of the particulars can be found in an answer I gave here. That answer also contains links to more information if you think it is something that would work for you.