[fangpenlin]

Hi, the author here.

I get where you're coming from. My books are also growing big right now, and indeed, they have become slower to process. Some projects in the community, such as Beanpost [1], are actually trying to solve the problem, as you said, by using an RMDB instead of plaintext.

But I still like text file format more for many reasons. The first would be the hot topic, which is about LLM friendliness. While I am still thinking about using AI to make the process even easier, with text-based accounting books, it's much easier to let AI process them and generate data for you.

Another reason is accessibility. Text-based accounting only requires an editor plus the CLI command line. Surely, you can build a friendly UI for SQLite-based books, but then so can text-based accounting books.

Yet another reason is, as you said, Git or VCS (Version control system) friendliness. With text-based, you can easily track all the changes from commit to commit for free and see what's changed. So, if I make a mistake in the book and I want to know when I made the mistake and how many years I need to go back and revise my reports, I can easily do that with Git.

Performance is a solvable technical challenge. We can break down the textbooks into smaller files and have a smart cache system to avoid parsing the same file repeatedly. Currently, I don't have the bandwidth to dig this rabbit hole, but I already have many ideas about how to improve performance when the file grows really big.

[1]: https://github.com/gerdemb/beanpost

[asadjb]

Thanks for responding and your thoughts! Generally agreed with all you said.

However, I feel like maybe a different approach could be to store all the app state in the DB, and then export to this text only format when needed; like when interacting with LLMs or when someone wants an export of their data.

Breaking the file into smaller blocks would necessarily need a cache system I guess, and then maybe you're implementing your own DB engine in the cache because you still want all the same functions of being able to query older records.

There's no easy answer I guess, just different solutions with different tradeoffs.

But what you've built is very cool! If I was still doing text based accounting I would have loved this.