Fork me on GitHub
Jacob O'Bryant23:04:10

Here's a question about Crux on Hacker News in case someone more knowledgeable than me wants to respond: > Why would you need a special database to implement this feature? Usually its just modelled by having 2 date fields and querying as appropriate. (My response would be "I don't know man, I've never actually used bitemporality much yet")

🚀 9
🙏 3

Fowler gets major props for quoting Doctor Who! 🙂


yeah - 'querying as appropriate' is fine when you've only got a couple of tables, but when you have explicit user-managed columns you then have to take them into account in every join of every query 🙂


more to manually performance optimise, too - to an RDBMS they're just ordinary columns - their inclusion in every join may be enough to cause it to choose an unsuitable plan; a bitemporal database knows more about them and so can optimise on your behalf


Crux, for example, indexes the content and the temporal information separately, so that a decent amount of the query can be executed on the content alone


So... "Performance"?


haha, yep 🙂 although day-to-day I think I'd value the ease and correctness higher, not having to worry that anyone querying the database has correctly applied the temporal filters every time - for the common 'as of now' case you pretty much transact and query Crux as if it's a regular atemporal database, but you still have the temporality support when you need it