Just wanted to check in and say that we've fixed this issue with beta 10, The JSON parser is now 153 times faster, with parsing nested objects and blocks specifically (was biggest problem) has 3666x improvement
Have you looked into datalog? It is a single query language that can query all those models. It really doesn't care about the underlying model! Datomic itself is somewhat limited compared to surrealdb, no geo and only limited fts support for example, but the query language is amazing!
Yeah, datalog is a pretty unique and clever language, which unfortunately also means that most people won't bother to learn it 😅Its hard to strike the right balance between flexibility and simplicity.
XTDB supports datalog queries, and I believe so does TerminusDB. I'd also prefer the ability to write queries in Datalog, but haven't found a database that works well in an offline-first or mobile environment, and it looks like maybe SurreralDB could be if paired with Tauri? Though it also seems like maybe there's a possibility to get XTDB running in a mobile application through GraalVM, though nobody seems to have tried and I'm probably not smart enough to be the first.
@@David-iq1kd, you can use SurrealDB embedded, like you would with SQLite, currently possible with Rust (so Tauri is an option yes) and beta in Python and coming soon with Nodejs so you could use react native/electron and more. If there is enough interest we might add datalog in the future, but currently there is not a plan for it. We do however have a plan for implementing GraphQL natively.
No offence, however you missed the essence of why very smart people invented different models. Originally there was hierarchy. It is easy to understand, however, it is very limited in providing answers outside how they are constructed. So, you could for instance have all your customers and from each customer all their orders and in each order all items purchased. This would allow you to find the answer on what each customer had purchased, but not which items were purchased most often. Relational models came as clever answer. By having clients, orders, order items, items you could create almost any join in a way that would provide a correct answer. You could even ask the question: what items have never been purchased. Obviously, the puzzle then was that joins are not human friendly and might be costly in CPU power. And this is where the graph came in. By naming a type of join into some verb you could in somewhat broken English understand how things were related to other things. Another solution was back to document databases that are similar to the old hierarchy. It allowed finding an object and almost directly having all items related together.
Thanks for the feedback! It was intentionally made very short and simple, which means there were a lot of things I needed to leave out. I appreciate you taking the time to share more of the backstory here. - Alexander
Sure! Surrealdb is really the future … keep up the good work surreal team
I’d love to see more tutorial educational like content. Or something like the mongodb university for SurrealDB.
It looks quite nice! This is going to take off at some point.
The migrator should be integrated into the main repo imho.
Surreal is amazing. Just waiting for the dev team to fix the large json update/insert issue to be fixed! Please!
We're actively working on fixing it, wait will be over soon!
Just wanted to check in and say that we've fixed this issue with beta 10, The JSON parser is now 153 times faster, with parsing nested objects and blocks specifically (was biggest problem) has 3666x improvement
Have you looked into datalog? It is a single query language that can query all those models. It really doesn't care about the underlying model! Datomic itself is somewhat limited compared to surrealdb, no geo and only limited fts support for example, but the query language is amazing!
Yeah, datalog is a pretty unique and clever language, which unfortunately also means that most people won't bother to learn it 😅Its hard to strike the right balance between flexibility and simplicity.
@@datastorydesign so true, SQL is omnipresent and well known, hmm
XTDB supports datalog queries, and I believe so does TerminusDB. I'd also prefer the ability to write queries in Datalog, but haven't found a database that works well in an offline-first or mobile environment, and it looks like maybe SurreralDB could be if paired with Tauri? Though it also seems like maybe there's a possibility to get XTDB running in a mobile application through GraalVM, though nobody seems to have tried and I'm probably not smart enough to be the first.
@@David-iq1kd, you can use SurrealDB embedded, like you would with SQLite, currently possible with Rust (so Tauri is an option yes) and beta in Python and coming soon with Nodejs so you could use react native/electron and more. If there is enough interest we might add datalog in the future, but currently there is not a plan for it. We do however have a plan for implementing GraphQL natively.
No offence, however you missed the essence of why very smart people invented different models.
Originally there was hierarchy. It is easy to understand, however, it is very limited in providing answers outside how they are constructed. So, you could for instance have all your customers and from each customer all their orders and in each order all items purchased. This would allow you to find the answer on what each customer had purchased, but not which items were purchased most often.
Relational models came as clever answer. By having clients, orders, order items, items you could create almost any join in a way that would provide a correct answer. You could even ask the question: what items have never been purchased.
Obviously, the puzzle then was that joins are not human friendly and might be costly in CPU power. And this is where the graph came in. By naming a type of join into some verb you could in somewhat broken English understand how things were related to other things.
Another solution was back to document databases that are similar to the old hierarchy. It allowed finding an object and almost directly having all items related together.
Thanks for the feedback! It was intentionally made very short and simple, which means there were a lot of things I needed to leave out. I appreciate you taking the time to share more of the backstory here. - Alexander
Potato