Advertisement
Advertisement
β‘ Community Insights
Discussion Sentiment
86% Positive
Analyzed from 392 words in the discussion.
Trending Topics
#markdown#database#data#https#frontmatter#files#yaml#file#app#read
Discussion Sentiment
Analyzed from 392 words in the discussion.
Trending Topics
Discussion (13 Comments)Read Original on HackerNews
Much better off storing this in an embedded graph database and use cypher.
MVCC, Indexes, Strong typing, WAL, changefeeds.
The simplicity of markdown and JSON are deceptive. SQLite is a solid choice, but then you deal with graph-relational impedance mismatch.
In any case, nowhere is it indicated why this approach (no matter what you call it) should be preferred over e.g. recfiles.
https://ddot.it
Disclaimer: My project
[1] https://silverbullet.md/
Specifically, my observation was lots of people use a collection of markdown files (or other data formats) in a git repository to crowdsource data. This ties in really nicely with a lot of static site generators.
I was interested in seeing if a tool could help data reuse and help people who aren't comfortable with git contribute.
I told AI to improve on that format and told me having to read all files just to get the frontmatter data is optimizable, sooo... to the trenches B)
AI > The problem with Frontmatter+YAML is O(n) read complexity. To know if a file is a "Person" or a "Meeting Note," the parser must read the entire file into memory, parse the YAML block, and then discard the content. For a vault of 10,000+ files, this becomes a massive I/O bottleneck
Your filesystem is very much not a database, and you risk data corruption and loss by using markdown files as a database, especially if you have multiple programs reading and writing to and from the same files. Things will start getting weird and you will start rebuilding an ACID compliant database engine in your application layer.
That said, I love markdown. It's great. Simple.