There was a recently published meta review on the subject of Schema Evolution that is probably far more practical.<p><a href="https://www.worldscientific.com/doi/10.1142/S2972370124300012" rel="nofollow">https://www.worldscientific.com/doi/10.1142/S297237012430001...</a>
I’ve always wondered why SQL doesn’t support variant types, and in this case especially.<p>If you’re going to store a sequence of values whose type can change over time, a variant is the obvious encoding choice. As new schemas are introduced, you add constructors to the variant.<p>On top of that, you can apply some basic structural reasoning to say eg a field can be indexed (possibly by different paths in each case) iff it exists in each constructor, or optionally with the awkward SQL nulls in case a field is not in each constructor (as they describe in the paper).<p>But then you could also use general variant deconstruction to decide on a case-by-case basis how to handle each version or subset of versions of a schema, and having that capability to represent variants in user data, independent of “evolving schemas” could have significant general use as well.<p>If you feel like having tuples and variants is too complicated, use dependent sigma types, so they’re all tuples, and then your schema language is much more expressive still.<p>It’s weird how much database systems have stagnated on this front.
A possible inspiration for Datomic [1], having the concept of time built into the database (specifically db time and not domain time) and a new query language capable of processing time.<p>[1] <a href="https://docs.datomic.com/datomic-overview.html" rel="nofollow">https://docs.datomic.com/datomic-overview.html</a>