> We should probably model a knowledge graph with a graph database!
I realize this seems intuitive, but the relational model has proven itself to be surprisingly flexible in its ability to store multiple different data models efficiently. Similar arguments were made about the suitability of document stores to social networking websites ten years ago, and I think we know how that panned out.
> SQL databases are indeed operationally simpler but that's because they have been around for much longer and are more battle-tested.
I wouldn't discount the age and battle-testing, though. They're the first choice for data storage for many good reasons. Not least of which is the flexibility and power of the relational model.
It's clear that graph query languages are more expressive for graph databases. What's not clear to me is whether there's anything fundamental about that expressiveness, or whether it will eventually be replicated in SQL. Have you tried using recursive CTEs before?
Well the other aspect of it is that DataScript is client-side. That said, we could use sqlite in browser or even IndexedDB at this point. Yes, a pure JS/TS alternative without a graph db implementation is possible. But when I started, I chose the same language and db to ensure parity would always be much more possible.
Haven't tried recursive CTEs before, maybe I should dig into it more!
> Yes, a pure JS/TS alternative without a graph db implementation is possible. But when I started, I chose the same language and db to ensure parity would always be much more possible.
To be clear, I think Datalog and Clojure are both actually really cool, I'm just a huge SQL fan too. I think the architectural decisions you made in this case make perfect sense :)
I realize this seems intuitive, but the relational model has proven itself to be surprisingly flexible in its ability to store multiple different data models efficiently. Similar arguments were made about the suitability of document stores to social networking websites ten years ago, and I think we know how that panned out.
> SQL databases are indeed operationally simpler but that's because they have been around for much longer and are more battle-tested.
I wouldn't discount the age and battle-testing, though. They're the first choice for data storage for many good reasons. Not least of which is the flexibility and power of the relational model.
It's clear that graph query languages are more expressive for graph databases. What's not clear to me is whether there's anything fundamental about that expressiveness, or whether it will eventually be replicated in SQL. Have you tried using recursive CTEs before?