Fork me on GitHub
#crux
<
2021-04-08
>
Jacob O'Bryant23:04:10

Here's a question about Crux on Hacker News in case someone more knowledgeable than me wants to respond: https://news.ycombinator.com/item?id=26744895 > 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")

🚀 3
🙏 1
seancorfield00:04:47

Fowler gets major props for quoting Doctor Who! 🙂

1
jarohen08:04:37

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 🙂

jarohen08:04:14

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

jarohen08:04:24

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

ordnungswidrig10:04:21

So... "Performance"?

jarohen10:04:18

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