> A time-varying relation is just what it says: a relation that changes over time ... Critically, the full suite of existing SQL operators remain valid on time-varying relations
Any relation by definition is supposed to change in time. So why do we need to introduce a special kind of relations? The authors essentially confirm that there is no difference between classical relations and "time-varying" relations.
Also, it is not clear how does it relate to EPL (in CEP) which is also based on SQL.
According to relational theory, relations are immutable sets of tuples. The way you “change” a relation is by assigning a new relation to the name, e.g.:
R1 <- R1 union R2
Is the relational algebra way of “inserting” R2 into R1. Of course, most RDBMS’s (and the SQL family of languages) are only reasonably faithful implementations of relational theory under some practical constraints.
But those differences re important, and I think the authors are proposing a new relational model (though I don’t think this is a totally new idea; I’m not a database researcher). One that incorporates time and history of a relation as first-class citizens of the theory, that allows sql to operate natively on both traditional relational-theoretic relations and streams of data. Pretty cool! Can anyone who knows more than me comment on how this relates to Kafka tables, which seems to me a similar concept?
Relations in most systems don’t implicitly store the time a change occurred or the past versions of a row, nor do they have a model for building a “now table” from an “event table”. When people talk about time-varying tables or temporal tables, they are describing event sourcing in a SQL context.
Any relation by definition is supposed to change in time. So why do we need to introduce a special kind of relations? The authors essentially confirm that there is no difference between classical relations and "time-varying" relations.
Also, it is not clear how does it relate to EPL (in CEP) which is also based on SQL.