Record Keeping paradigm
Book keeping and other record keeping tasks, benefit of not having a real deletation of data/infomation. Rather have a record of change.
Programming can be a chore, but for me it's a source of joy. It's something I do as a hobby, and I don't use LLMs much. It's about having fun and making a fool of yourself. It's not about how good it is, in this case, I'd rather just listen to music and drink a cup of tea. I enjoy the struggle to debug, the small beauty in understanding why a bug was there in the first place.
I chose SQLite3 because it's a SQL-based database that doesn't need a live server, just a single db file. The idea is to use a monolith to control the book records, so no collisions should happen. The IDs and other fields are kept very basic because of SQLite's minimal type support. Entries are ints and strings. The history of changes, saved as events, is stored as blobs, since retrieving these should only happen on rare occasions. Mostly the resulting changes are saved, while the more granular event-by-business-action log is timestamped, and its id relates to the resulting entries (account movements).
Space can be a concern, so I save attachments in a compressed format. By separating attachments, a linked
directory could be saved on a hard disk drive instead, as these will probably almost never get accessed after
saving. Only occasionally in an audit scenario.
The filename is the id from the db. This way, if there's ever a corruption scare, I could read the db as a
text file and find the metadata from the id. It also makes naming irrelevant, so filenames can't collide.
