4 ms·

You don't need a full blown ORM here. A rather thin access layer would suffice, as much I can see from the API. What I can see here, is that the data store is

You don't need a full blown ORM here. A rather thin access layer would suffice, as much I can see from the API. What I can see here, is that the data store is just a big JSON-file. So the implementation does not scale well (every save just writes the whole database and the database must be read in total to access any tiny bit of data). For any even medium sized application, it would be better to use a more sophisticated basis. Maybe as configuration database -- but even for that, I guess there are already better choices in existence. Edit: Upvoted the OPs post, because of the Vietnam-Link -- good read. Still, I would not throw RDBMSes totally out of the window. I think, we have learned a lot from them and in many, many cases they are just right. There are some cases of course, where object oriented schemes are more appropriate.

klibertp 11y ago
> You don't need a full blown ORM here. Precisely my point, you don't need an ORM with this LanderDB, but you'd need it with SQLite (unless you like using raw SQL, which is a fine preference too, of course). > What I can see here, is that the data store is just a big JSON-file. One possible use-case for this I recently discovered is storing bookmarks in Chrome (https://klibert.pl/output/jq_and_chrome_bookmarks.html https://klibert.pl/output/jq_and_chrome_bookmarks.html). I'm not saying LanderDB is the best option and as smt88 wrote there certainly are many alternatives. I'm just noting that LanderDB doesn't seem to occupy the same niche as SQLite. EDIT: oh, and I'm in no way involved with LanderDB, I just saw it a couple minutes ago :)