3 ms·

I haven't used `temporal_tables` but I have built similar temporal systems on Postgres in the past. (Judging by https://github.com/arkhipov/temporal_tables#usag

I haven't used `temporal_tables` but I have built similar temporal systems on Postgres in the past. (Judging by https://github.com/arkhipov/temporal_tables#usage https://github.com/arkhipov/temporal_tables#usage at least.) The trouble with these sorts of approaches is that they solve temporality the same way we did in the 90s: Add an `entity_history` table, timestamp your tx-time and valid-time, and add a trigger to version your entities. This must be done for each entity you want to version across your temporal plane. It would appear that `temporal_tables` doesn't support bitemporality yet. It only has tx-time (system time). But even if it did, this approach doesn't help you with live data. Because the `entity` table corresponding to the `entity_history` table still permits destructive updates, temporal queries are always in the realm of audits and can't answer questions about the application data directly. Add to that a completely manual system of querying the temporal information, and the resulting systems tend to get quite hairy, which is why Martin recommends avoiding bitemporality whenever you can. Unfortunately, that recommendation (while sound, for relational databases) means that bitemporality is expensive and manual if and when it's implemented. A bitemporal database like Crux encodes the temporal plane into all the data stored in it, making it transparent to the user. There's no up-front setup cost to bitemporality and a query's default time on both time axes is "now", allowing the user to ignore temporality entirely except in those few instances where it is required -- but when it is required, it is global.

jka 5y ago
Sure, I can appreciate that native support for a feature like this is nice. As I understand it, most implementations (including another one for bitemporality[1]) involve either audit tables, as you mention, and/or additional support columns. It's as if the "now" representation is simply a narrowed view within the full set of underlying, (bi)temporal data. That said, PostgreSQL encodes and has battle-tested decades of database functionality, including a surrounding ecosystem, so I'd be a little wary of switching technology even if it does solve one individual problem thoroughly. Everything has to start somewhere, though. [1] - https://github.com/scalegenius/pg_bitemporal https://github.com/scalegenius/pg_bitemporal
- jka 5y ago
  Perhaps this was an overly-skeptical perspective. Datalog (as featured in Crux) has certainly existed as a concept for a long time, although it hasn't (as far as I can tell) seen popular uptake.
tremon 5y ago
The SQL Standard actually specifies two related but separate approaches to versioning: - system-versioned tables, which is the focus of this extension. This can be implemented purely database-side, and the application doesn't even need to know whether (certain) tables are system-versioned. This is mainly intended to offer change tracking and auditing in a standard way, to replace all the home-grown solutions to do the same. - application-versioned tables, which I think Postgres already supports natively. This puts the application in control of the timespans in which a row is considered valid, and is probably what you would use for retroactive (or planned) updates to business records. I'm not sure if the standard specifies how these two versioning systems interact, but by combining both strategies, you could in theory have a full system-versioned record of who made which changes to take effect on which date.

jka 5y ago

Sure, I can appreciate that native support for a feature like this is nice. As I understand it, most implementations (including another one for bitemporality[1]) involve either audit tables, as you mention, and/or additional support columns. It's as if the "now" representation is simply a narrowed view within the full set of underlying, (bi)temporal data. That said, PostgreSQL encodes and has battle-tested decades of database functionality, including a surrounding ecosystem, so I'd be a little wary of switching technology even if it does solve one individual problem thoroughly. Everything has to start somewhere, though. [1] - https://github.com/scalegenius/pg_bitemporal https://github.com/scalegenius/pg_bitemporal

jka 5y ago
Perhaps this was an overly-skeptical perspective. Datalog (as featured in Crux) has certainly existed as a concept for a long time, although it hasn't (as far as I can tell) seen popular uptake.

tremon 5y ago

The SQL Standard actually specifies two related but separate approaches to versioning: - system-versioned tables, which is the focus of this extension. This can be implemented purely database-side, and the application doesn't even need to know whether (certain) tables are system-versioned. This is mainly intended to offer change tracking and auditing in a standard way, to replace all the home-grown solutions to do the same. - application-versioned tables, which I think Postgres already supports natively. This puts the application in control of the timespans in which a row is considered valid, and is probably what you would use for retroactive (or planned) updates to business records. I'm not sure if the standard specifies how these two versioning systems interact, but by combining both strategies, you could in theory have a full system-versioned record of who made which changes to take effect on which date.