Question

I’m very new to Python and I’m trying to write a sort of recipe organizer to get acquainted with the language. Basically, I am unsure how how I should be storing the recipes.
For now, the information I want to store is:

• Recipe name
• Ingredient names
• Ingredient quantities
• Preparation

I’ve been thinking about how to do this with the built-in sqlite3, but I know nothing about database architecture, and haven’t been able to find a good reference.
I suppose one table would contain recipe names and primary keys. Preparation could be in a different table with the primary key as well. Would each ingredient/quantity pair need its own table.

In other words, there would be a table for ingredientNumberOne, and each recipe’s first ingredient, with the quantity, would go in there. Then each time recipe comes along with more ingredients than there are tables, a new table would be created.

Am I even correct in assuming that sqlite3 is sufficient for this task?

Answer 1

1. Yes, SQLite3 is sufficient for the task.
2. Each ingredient/quantity pair does not need its own table.

One quick way to pick up the basics of SQL is to fiddle with the Command Line Shell for SQLite and knock around some data interactively before you start writing Python. SQL isn’t too difficult. It can be difficult, when you really start flexing it, but I imagine you’ll be able to learn enough for your needs pretty quickly. IMHO the missing link in your understanding of modeling data with an RDBMS is grokking one-to-many and many-to-many relationships.

Your approach would probably work, but it seems roundabout. There are a lot of solutions to modeling that sort of data. I’m thinking of something like:

TABLE recipes
    name text primary key
    preparation text

TABLE ingredients
    recipe foreign key
    name text
    quantity double

If you want to interact with your DB in a Pythonic way, look at SQLalchemy or another ORM. (My opinion is that they’ve been more trouble than they’re worth on my own small projects.)

Of course, you could also make each recipe document a dictionary object and then shelve them all. (Sorry, broad question – broad answer.) This should work very well; a lot of us just jump towards SQL because our first hobby projects were web apps.

My final piece of advice (from the experience of a true non-expert) is to just start coding. The scale of the project isn’t so large that you couldn’t refactor in a different method of persistence, and when you hit a wall you’ll find it a lot easier to solve the real problem than a hypothetical one.