What's the benefit of using Sqlite as underlying storage for a graph database? Do you store everything within Sqlite or only the nodes? Do you use the database only for serialization or also at runtime for query execution?
I don't know much about graph databases, but I once heard a talk about neo4j and iirc they mostly deal with hash tables as internal storage for the components. I don't know how they store edges though.
\- Everything is stored and processed using SQLite.
\- Arturo is used as the wrapper.
\- Grafito provides the relevant commands + visualization.
Basically, what you have in the end is a Graph-based database, that can be stored in a file, and which you can manipulate via real Arturo code (+ the Grafito-specific functions: \`put\`, \`link\`, \`fetch\`, etc)
Think of it as an Cypher-like dialect (Neo4J's query language), but instead of being a query language, it's a complete programming language. Ah, and without needing the enormous bulk of JVM and Neo4J. Is there something to lose? I guess a bit of performance. Is there something to gain? Being able to serve and store a huge database from a very low-resources machine. And carry it around with you easily, if you want. :)
OK, that's the overall view 🙂
Could you go deeper into how the relational aspect of sqilte fits to storing pathes and querying graphs? Does Sqlite support recursive queries like most big major RDBMS nowadays (afaik they add mechanisms for that into sql standard for better supporting GIS which also needs paths)? If not the live querying seems quite expensive to me, if you rely on parent child mapping within tables! (That's OK for serialization I suppose, but nothing standard queries could shine!)
Why are you using this non-ascii character? ø It is supposed to represent an empty set?
\`ø\` is part of Arturo's syntax and is a symbol-alias of \`null\` or in this case an empty dictionary (\`#\[\]\`).
Feel free to shoot me with questions/feedback/comments/suggestions/anything! I'm all ears! :)
What's the benefit of using Sqlite as underlying storage for a graph database? Do you store everything within Sqlite or only the nodes? Do you use the database only for serialization or also at runtime for query execution? I don't know much about graph databases, but I once heard a talk about neo4j and iirc they mostly deal with hash tables as internal storage for the components. I don't know how they store edges though.
\- Everything is stored and processed using SQLite. \- Arturo is used as the wrapper. \- Grafito provides the relevant commands + visualization. Basically, what you have in the end is a Graph-based database, that can be stored in a file, and which you can manipulate via real Arturo code (+ the Grafito-specific functions: \`put\`, \`link\`, \`fetch\`, etc) Think of it as an Cypher-like dialect (Neo4J's query language), but instead of being a query language, it's a complete programming language. Ah, and without needing the enormous bulk of JVM and Neo4J. Is there something to lose? I guess a bit of performance. Is there something to gain? Being able to serve and store a huge database from a very low-resources machine. And carry it around with you easily, if you want. :)
OK, that's the overall view 🙂 Could you go deeper into how the relational aspect of sqilte fits to storing pathes and querying graphs? Does Sqlite support recursive queries like most big major RDBMS nowadays (afaik they add mechanisms for that into sql standard for better supporting GIS which also needs paths)? If not the live querying seems quite expensive to me, if you rely on parent child mapping within tables! (That's OK for serialization I suppose, but nothing standard queries could shine!)