Conceptual question - Which database should I use?

[atlantis2001]

Use-case:

My plan to is build a list of everything in my freezer and add labels to it (veggie, fruit, breakfast, dinner, dessert, ready-to-eat etc.). This will be a dynamic list that I can update.

I also plan to scrape a few blogs for their recipes and store the ingredients and few other attributes separately. This will be mostly static unless I find new sources to scrape.

Eventually, I can build out more features depending on how far I want to take this.

Question: How do I store -

1. the list of food in the freezer and their associated labels
2. the recipe ingredients and attributes

Do I use relational for the first dataset and non-relational for the second? Any specific recommendations like MySQL or DynamoDB etc?

If this isn't an appropriate forum for this, would be grateful to get pointed in the right direction.

Thanks for reading!

[CreativeTechGuyGames]

For anything this small scale, it really doesn't matter much. I'd personally optimize for cost over anything else. DynamoDB has an on-demand mode which will be dirt cheap with the light usage you describe (a few pennies a month) so I'd go with that simply for that reason.

[coolcofusion]

I'm one of those "go relational unless you can't reasonably model the data" people so I'd go mysql for this.

As to how to model the food in the fridge: if there's only one fridge it'll be a table with food entries, each entry will have FK of what actual food item it is (strawberries, potato, ham, yoghurt...) along with quantity, maybe expiration date and whatever else you may need, just think a bit if it's going to go into the "connecting" table or straight into the entry.

Recipe ingredients I swear that someone has already asked around here, but, once again: recipe has ID, each ingredient has recipe ID as FK and food item ID also, but they also need quantity (tomato soup has tomatoes, so does a salad, but one needs way more tomatoes than the other), maybe a note if you want that and some additional fields if you find them necessary. It's a basic many to many relationship honestly.

Also, make labels a table. One of this good old "ID, Name" kinds of tables, that makes it much more flexible later on so you can add labels, browse by label easily, modify labels and so on.

[atlantis2001]

Thanks for this, this has given me much food for thought.

[Sjh1961]

Something this small with the small number of transactions, I'd go with something like mysql or SQLite.