What would be a better way to create my database of food? [closed]

Question

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.

Closed 8 years ago.

I have taken on the project of creating a relation database which will contains all the basic ingredients we use in modern cooking. As you could imagine, there are going to be thousands of items. I do not have much sql experience so I am having trouble arriving at a seemingly efficient way of storing the ingredients. If you go here http://en.wikipedia.org/wiki/Outline_of_food_preparation#General_ingredients you can see the list I am currently trying to put into my database.

My database current has a table for every main and sub category of food ex. a table for cereals and a different table for wheat. At first it seemed okay to do this, but then i realized that there are going to be dozens more sub categories. For each item in that wiki list there are more tables and more tables that I must create. I feel like this plethora of tables will make my project very inefficient. Is there a better way to create my database? Or am I on the right track? Here is an example of the columns in my tables:

    id INT(11),name VARCHAR(45),parent INT(11),img VARCHAR(45),desc VARCHAR(45)

parent INT(11) will be a foreign key to whatever the parent table is, so I figured they will all connect this way. Any advice is appreciated! ~THANKS

Answer 1

I would first not recommend storing all these in separate tables -- it'll drive you crazy :-)

Instead however, I think you have 2 options.

Option 1 (Adjacency List Model) -- Consider using a single Foods table, with FoodId, FoodName, ParentFoodId, AnyOtherAttributes you wish to store. This is easiest to store the data, but can be a little more troublesome to return your results as you'll need to join on the same table multiple times to return levels.

Option 2 (Nested Set Model) -- This option still would have the single Foods table, but instead of having a ParentFoodId, you'ld have 2 columns, left_index and right_index. This is perhaps a little more complicated to understand at first, but can be easier to query if you have several unknown nested parent-to-child relationships.

Take a look at this article for some further explanations:

http://mikehillyer.com/articles/managing-hierarchical-data-in-mysql/

Good luck.