[gh02t]

It could be worth it if you need to do lots of relational queries with complex inventory management. I was imagining e.g. an RPG that would ship the stats for all its items in a sqlite data file and then you can store the player's stats and inventory with foreign keys pointing to the item table. You're gonna have to store that data somehow and if you've got enough items and/or complex enough inventory management it seems like maybe you might want to consider sqlite as it already exists and provides a lot of relevant features. I don't consider size so much as whether or not there is a need to persist data and the complexity of relationships; size is more of a factor in "should I use sqlite or should I use a beefier database like Postgres."

I know sqlite is used heavily on iOS and Android and a lot of people use it as a glorified serialization format. Probably not the best in most cases but hey sqlite is so lightweight that it doesn't have much downside. I tend to use it as intended as a lightweight database myself but hey if it works it works.

[int_19h]

It is far easier to store such structures as object graphs in-memory (i.e. your "foreign key" is a pointer/reference to the actual object). The navigation patterns would mostly be looking up properties on the item referenced by inventory, so it's not like you need to do joins etc (but even if you did, a join on in-memory object graph is still pretty easy and blazing fast).

For C++ especially, I would recommend looking at Boost multi_index library. This gives you the ability to do fast lookups on a variety of keys across the same data.

Pretty much the only benefit I can see from SQLite in those small dataset scenarios is when you need persistence and the ability to change subset of data in an atomic way (if you only need to save the entire in-memory dataset atomically, you can always just do the rename trick to ensure atomicity with far less overhead). Well, and, I guess, optimization of complicated queries - but I'm somewhat skeptical about the ability of their optimizer to use indices in a query that's really complicated; and simple ones are trivial to do explicitly.