0

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?

agf
  • 171,228
  • 44
  • 289
  • 238
abroekhof
  • 796
  • 1
  • 7
  • 20

4 Answers4

3
  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.

Community
  • 1
  • 1
Cody Hess
  • 1,777
  • 15
  • 19
  • Good answer, but your comment about ORMs needs to be corrected. I think for someone who hasn't done anything with SQL yet, an ORM is a much more easier and faster way to get started with database programming. – schlamar Oct 19 '11 at 22:14
  • 1
    Hi, thanks for the thorough answer. The one-one/many, etc. was indeed very illuminating. I see how your structure can solve the problem now. Shelve looks pretty straightforward as well. Sorry about the broad question, but as a beginner it just looks like an endless sea of options out there. Sometimes the hardest part is figuring out where to start – abroekhof Oct 20 '11 at 07:23
  • @ms4py I don't think I can "correct" an *opinion*. I'd agree that frameworks with built in ORMs like Django are straight-forward and delightful, but I implemented SQLalchemy for a command line app and it simply wasn't worth the complexity for my very simple use case. – Cody Hess Oct 20 '11 at 20:03
  • There is the declarative mode of sqlalchemy which makes the data modeling as easy as with Django (http://www.sqlalchemy.org/docs/orm/extensions/declarative.html). And before that there was the Elixir Layer: http://elixir.ematia.de/trac/. Very interesting in this discussion is the blog post of Armin Ronacher: http://lucumr.pocoo.org/2011/7/19/sqlachemy-and-you/ – schlamar Oct 21 '11 at 00:02
2

Just a general data modeling concept: you never want to name anything "...NumberOne", "...NumberTwo". Data models designed in this way are very difficult to query. You'll ultimately need to visit each of N tables for 1 to N ingredients. Also, each table in the model would ultimately have the same fields making maintenance a nightmare.

Rather, just have one ingredient table that references the "recipe" table.

Ultimately, I just realized this doesn't exactly answer the question, but you could implement this solution in Sqlite. I just get worried when good developers start introducing bad patterns into the data model. This comes from a guy who's been on both sides of the coin.

LJM
  • 6,284
  • 7
  • 28
  • 30
0

You might want to look into the Dabo framework (http://dabodev.com/)

Here's a step by step guide to building applications with it: https://docs.google.com/View?id=dg79jzmg_85f737ww6x

Acorn
  • 49,061
  • 27
  • 133
  • 172
0

You are going to have to answer your own question here. From a technical standpoint, if you want to store something in Python it can be as easy as:

import pickle
pickle.dump(myObject, myFile)
"Then read it back"
myObject = pickle.load(myFile)

If you happen to need something more than just data storage, then you should start looking at a database. There are a ton of databases out there, and sqlite is almost certainly up to the task.

Clarus
  • 2,259
  • 16
  • 27