stt19
commented
7 years ago From my understanding, the way we are going about the database for our application is as follows:
- There is a "main" table for all foods: Food. This has the single attribute FoNo which acts as the primary key for ALL ingredients across all the "sub-foods".
- For each different category, there is an appropriate table (Meats, Veggies, Fruits, etc.). All of these tables reference the Food table - specifically the primary key FoNo. This is to ensure that even across all ingredients in differing tables, they will have a unique identification number so that there are no duplicate IDs.
- Additionally, in each sub table there is TypeOf, which will be used to name each individual ingredient. For example for Chicken, it would belong to the Meats table, and the value for TypeOf would be "Chicken."
- In the Recipes table, each recipe will have a particular ReNo as its primary key. Depending on how many ingredients belong to each recipe will determine how many rows are created for that particular recipe. This way, if somebody wants to know all of the ingredients in a recipe, they would just make a query to return all the rows that have a specific ReNo number.
I added Fruits and Grains tables to the .sql file. With this, I will next work on creating some User tables that keep track of all the ingredients that each app User has.
Because I am still less experienced, I would like to devote some time to making sure I understand Eddie's code. By doing this, I will be able to make similar contributions so that everything is uniform (and correct).