I'm new to mysql and I have to do a kitchen inventory database with recipes for a school project. I'm trying to get a query that shows recipes and users when users have all the ingredients to that recipe. I'm trying to work with the following tables for this query:
Products
ProdID
name (brand included)
tag - FK
Tags (Since there are different brands of products, a tag table to associate each product to a generic type, like orange juice)
TagID
name
Recipes
RecipeID
Name
Description
Ingredients (To associate all the ingredients with each recipe)
IgrID
TagID - FK
RecipeID - FK
Inventory
InvID
UserID
ProductID - FK
QTY
My idea was to get all the ingredients a user have and then check if they complete a recipe, but I don't know how to put together all the tables to get the first part. I tought of doing a join with users ingredients and recipes for the second part, I don't know if it would work though. Maybe the structure I made is unnecessarily complex too. Could anyone give me a hand?
Related
I'm creating one project for restaurants where user can browse and choose food. I didn't made before such a think and have some troubles with design and relations in database tables. This is the case
1. Restaurants
2. Customer click on restaurant-1
3. Customer get menu list for foods and drinks
4. Customer browse the food via sub-categories ( Salads, Drinks, Desserts and so on )
5. Customer choose some food and drinks...
As I can see here I would need 4 main tables restaurants, meals, meal_types and menu. Table Restaurants will hold restaurants
id
name
menu
image
text
address
Table Meal_types will hold main meal category - Drinks, Salads, Desserts and so on
id
name
Table meals will hold all foods/drinks
id
name
image
text
weigh
price
Table menu must keep which food/drinks to which restaurant to show when is selected.
id
name
So here is the tricky/hard part for me. How to make relations between them. One of the relations that I see and must have is between meals and meal_types. But others? How to connect restaurants with them and when user click on some restaurant to see the food that is served only from this restaurant. First thought for me was with this table menu but don't know how exactly.
I found it easier to Name the ids according to the items they represent. So I would suggest to Name the column id in your table restaurant Restaurant_id. This might help you Keep the general view in your relations.
Start from your smallest part: Your table meals. You have to combine this table with your Meal_types table since you have a 1:1 relationship between both (each meal has exactly one type, so just add another colum meal_type to meals).
Second you have your restaurants.
Now you just need an Information about the meals a Restaurant offers. This Translation table is your table menue and holds columns like this:
Restaurant_id,
Meal_id
To get the menue of a certain Restaurant you would query
SELECT
meals.meal_type, meals.name, meals.price
FROM
restaurant, menue, meals
WHERE
Restaurant.restaurant_id = menue.restaurant_id
AND menue.meal_id = meals.meal_id
AND Restaurant.name = 'Mc Donald's'
I have table pizza. It includes fields like cost, id, name (of pizza), and ingredients.
I also have table ingredients, with name of ingredient, and id. How to i put in table pizza ingedients for example 1,2,4,15, and be able to get that ingredients name from table ingredients?
Table Pizza:
id name cost ingredients
1 Vegie Pizza 12,59 1,2
Table Ingredients
id name
1 cheese
2 broccoli
3 pepperoni
I would like to get for egzample name and ingredients:
Vegie Piza - cheese, broccoli - 12,59
Or be able to order Vegie Pizza with pepperoni.
How do i connect this two tables in a way I described?
First of all donot store relations as comma separated values instead use junction table to relate 2 entities for this see Database Normalization
For your current solution you need to use find_in_set in join condition
select p.id,group_concat(i.name) ingredients,p.cost
from
Pizza p
join Ingredients i on(find_in_set(i.id,p.ingredients) > 0)
group by p.id
Fiddle Demo
You should have a table PizzaIngredients, with one row per pizza and per ingredient in the table. Someones, one doesn't have control over the data structure being used. If so, there is a solution in MySQL:
select p.name, p.cost, group_concat(i.name)
from pizza p join
ingredients i
on find_in_set(i.id, p.ingredients) > 0
group by p.name, p.cost;
However, a junction/association table is a much better way to store such data in a relational database.
I'm trying to create a site related to recipes where users can add custom meals, and within meals they can add foods and then list the ingredients of the foods. For example:
Meal = Dinner
Food = Hamburger
Ingredient = Tomato
Users can select foods from a pre-filled database of food items. They can also add ingredients from a central ingredients database. So the same food and ingredient ids can be used by any user of the site.
The challenge I have is ensuring the food_has_ingredients table is linked to the user somehow. In the diagram below the meal is associated to the user. Since the foods and ingredients ids can be re-used by multiple users I can't rely on those ids to determine which user adds ingredients to a food.
Take this example:
User 1 adds the food "hamburger" (id 10) to the meal_has_food table, then associates the ingredients "ketchup" (id 20) to the food_has_ingredients table.
User 2 adds the food "hamburger" (id 10) to the meal_has_food table, then associates the ingredients "pickles" (id 21) to the food_has_ingredients table.
If someone does a search get all ingredients from the meal hamburger (10) and limit it to one row, it would always give the first person's entry. So I've associated the meal id as a foreign key that way I can say get the ingredient for hamburger that belongs to meal id X.
I'd like to know if that makes sense or if there's a better way.
Here's a rough db schema:
I have a 'customers' table. Each record contains a customer name, email, address, etc.
I have an 'skus' table. Each record contains the name of an SKU. e.g. "Super Software Bundle".
An SKU represents a purchaseable item at a single price point. The purchased item can include one or more products.
e.g. The SKU record named "Super Software Bundle" may represent two products: product1 and product2.
For usability/ease reasons, other tables need to keep track of not only skus purchased, but the individual products a customer may have access to.
Question: how should I represent the variable sized nature of the SKUs in the database, where an SKU can represent from 1 to n products? Thanks for any help.
You will need a third table, that manages the relation between SKU and products, as a product may be part of more than one SKU (I guess). You have to model a m:n-relation.
product
id
name
price
...
sku
id
name
price
...
sku_product
id
sku_id
product_id
If I'm reading this right, you'll need a SKU table and a products table, and the products table will have a foriegn key to the SKU table.
My question is how to model transactions for different types of products.
So there is a Transactions table:
TransactionId(pk)
Amount
Method
AuthorisedBy(fk)
And there are different tables for different types of products.
Books table:
BookId(pk)
Name
Description
Price
And a Pens table:
PenId(pk)
Color
Description
Price
And a table for pencil sharpening services:
SharpenId(pk)
Description
Price
Now my question is linking the transactions with the particular id's of the different items.
One method was to have in the transaction table:
TransactionId(pk)
Amount
Method
AuthorisedBy
ProductType
ProductTypeId(fk)
Where product type would refer to the title of the table, eg Books and the product id would refer to the BookId in that case.
OR another method would be to have a linking table of 'products' that refer to each different id of the other tables, so the Transaction table would look like this:
TransactionId(pk)
Amount
Method
AuthorisedBy
ProductID(fk)
and the products table would look like this:
ProductId(pk)
PoductType
ProductTypeId(fk)
But then this is a table that is exactly the same as the transactions table. So my question is how do I efficiently link the different product type tables to the transactions?
Please note I am not modelling a school pencil sharpening service, they're just examples :P
First of all i dont like the DB model. You need only one table for product definition that can hold columns that describes every product:
(table)Products: ID - PK, Name, Description, Color, Price, ProductTypeID - FK
You need additional table that explain the type of the product, it's category let say:
(table)ProductTypes: ProductTypeID - PK, ProductTypeName
And for registering transactions you will need only one table:
(table)Transactions: TransactionID, ProductID - FK, Amount, Method, AuthorizedBy
I think this schema will be OK for you to resolve your issue.
Happy coding.