I am making a drink database with two tables Drink and Ingredient. Additionally there is an association table DrinkIngredients that connects these two so i can search which drinks contain a specific ingredient as well as which ingredients make up a certain drink.
Problem is that different drinks require different amounts of ingredients. So if I have two drinks, for example a Screwdriver which has Vodka and Orange Juice in the association table for it, as well as Tequila Sunrise which has Tequila an Orange Juice in the association table. I want to be able to do a query for Screwdriver and then query Screwdriver.Ingredients and get a list like
Vodka: 1 unit
Orange Juice: 1 unit
but then also query TequilaSunrise.Ingredients and get
Tequila: 1 unit
Orange Juice: 2 units
How do i go about adding additional information to the association table? or do i need to add a entirely new association table thats a subtable of the association table i already have for the amounts?
Here is a link to my models.py file
In my opinion, just add a new column to Drinkingredient table with quantity
Related
Let's say my company is producing medical products, these products are used in many different lab testing instruments. The business logic hierarchy goes like this:
A lab has multiple locations (Up to thousands)
A location has multiple departments (Chemistry, Hematology, 3-5 per location)
A department has multiple instruments (No more than 10-20 instruments per location)
An instrument has many products.(No more than 1-5 product types per instrument)
The table structure currently mirrors the business logic, like displayed on the left. I suggested we make a small change, displayed on the right.
What are some pros and cons of each approach? I feel like the left-hand side approach might be a bit slower due to chaining so many Joins in a row.
The biggest "con" I see to the approach on the right-hand side is that you lose the association between Department and Location. For the relationships that you described atop your post, the structure on the left is correct from a design perspective.
HOWEVER...
The design that you have means that the Mass Spectrometer at your San Antonio facility will have a different ID than the one at your Denver facility. Is that intended?
------------------ revision after discussion in comments ------------------
You've described a couple of many-to-many relationships - a location will have multiple instruments and multiple locations can have the same instrument (e.g. Mass Spectrometer). To support that, you'll need cross-reference tables. Here's an initial sketch. My standard is to call the table's primary key "ID", and any field called "[table-name]_ID" is a foreign key to the corresponding table:
Lab
ID
Name
Location
ID
Lab_ID
Street_Address
City
etc.
Department
ID
Name
Location_Department -- this lists the departments at a given location
ID
Department_ID
Location_ID
Instrument -- Scale, Oscilloscope, Mass Spectrometer, etc.
ID
Name
Description
Location_Department_Instrument -- inventory at a given location
Location_Department_ID
Instrument_ID
Instrument_Serial_Number
Let me know if this makes sense.
I have an application which handles the creation of different shop entities.
The process:
1. User registers to the website
2. User creates a shop (with various attributes)
What I have so far for database tables is:
[USER]
user_id
[USER_TO_SHOP]
user_id
shop_id
[SHOP]
shop_id
The above design covers the need for 1 user to have many shop entities under their account.
What I want to achieve now, is to have shop entities which are standalone but also have shop entities which are a part of group of shops
Chain of Shops example:
McDonalds Address X Chicago
McDonalds Address X New York
McDonalds Address X Boston
How should I proceed with my database design in order to support chain of shops but also standalone ones? Best practices are really appreciated!
*by standalone I mean a shop entity that does not belong to a chain
Off the top of my head I'd have a locations table and rename shop to company so single companies go into that table but can have multiple locations. Then users are associated with a company location.
There are many ways to achieve what you want, so, answers will be subjective since we don't really have the whole picture.
From what you're saying, a shop can belong to between 0 and 1 chains? If so, I would simply add one extra table and add a foreign key to the shop table:
[CHAIN]
chain_id
chain_name
[SHOP]
shop_id
chain_id
Well, for chains, you could have something like this, just like you have for users:
[CHAIN]
chain_id
[CHAIN_TO_SHOP]
chain_id
shop_id
Not sure what you mean by a standalone shop though - if you mean a shop that isn't owned by a user or a chain, could be something like this:
[STANDALONE_SHOP]
shop_id
But I would question the need for such a table, since a standalone shop could be assumed by an absence of an entry in CHAIN_TO_SHOP or USER_TO_SHOP
I'm setting up a new database and I'm coming across a circular reference and I'm unsure of the best way to design this.
so here it is in plain English.
I have a recipe. the recipe calls for ingredients. this is all fine and good except one of the ingredients for the recipe might require another recipe or it might be a store bought item.
for example:
I want to make a salad (recipe)
It will have lettuce, carrots, onions (All good so far. just store bought ingredients.)
but I want to have ranch dressing. (uh oh, I can buy ranch dressing at the store but I have a recipe for ranch dressing that I want to use to make the ranch dressing.)
how would you go about creating the recipe and ingredients tables in the best fashion? I have a thought all ready on how to do it but It involved circular referencing and all the web sites say stay away from it.
I would suggest the following tables:
a) Recipe - name, description, isingredient and other information
b) Ingredient - name, description, fromstore (yes or no value if its bought from a store), recipieid (the id of the recipe for this ingredient). This enables ingredients to have recipies
c) recipie_ingredients - receipieid, ingredientid (basically this ties a recipe to its ingredients)
The advice is correct, since you can end up in a circular loop form ingredients to recipies etc
UPDATE: I would recommend adding an isingridient column to recipe so that only recipes which are known to be ingredients are selectable to add to the Ingredient table. This can help reduce the chances of circular references
I come from frontend background, so I apologize if this db question seems dumb.
Say I have a database that handles orders of car and car accessories. If Car is non-customizable, then everything is easy-peasy. For every order, we simply need to associate the OrderId with the Car's ProductId. But a Car is a Product that can contain one or more Product like navigation, seat heater, etc. And users can also purchase those accessories Product separately.
How should we handle this best? Should every Product a user orders be given a unique ProductOrderId in the order table and if that Product can contain another Product, then we put it in a table that associates ProductOrderId with ProductId?
If we do this, would the db grow out of control? Seems a little inefficient to me. I have a feeling there is a better way.
If you look at how complex products are typically billed, the main item and each of its options are treated as separate line items in the bill of sale. In that kind of scenario, a car is a product and each of its accessories are also products. You can have an involuted relationship on product to indicate which accessories go with which type of car.
Your data model for this scenario would look something like this:
Alternatively, you could have a scenario where you want a level of abstraction such that your bill of sale contains only a single item, being a fully accessorized car. That requires the order item to become more like a header in a bill of materials, like so:
I'm working on building a database that will search for recipes by ingredients.
For example, I think I plan on populating the database with types of ingredients that are accepted, but I don't want to have to parse the string which includes all the ingredients in a particular recipe. I was thinking of making just like an list of acceptable ingredients table and searching through that somehow to see if it exists or not. I feel like this will be a very taxing operating though, and I want this to be as efficient as possible.
What is the best way to structure something like this? I have a couple of ideas, but they just seem so inefficient.
If someone searches for recipes with butter, mushrooms, and spinach, I want it to return a recipe with any of those ingredients in it.
Looking forward to hearing some suggestions on this.
This is about as easy as relational databases get...
Table One - Ingredients
[ID] [Name] [Description?]
1 butter delicious cow output
2 bread wholegrain please
Table Two - Recipe Basic Data
[ID] [RecipeTitle] [RecipeAuthor] [RecipeSteps] (maybe as BLOB text?)
1 Happy Toast Andrew butter on bread, then toast bread, etc.
Table Three - Recipe Needs (many-to-many)
[RecipeID] [IngredientID]
1 1 (toast needs butter)
1 2 (toast needs bread)
That should get you started.
EDIT - sample query
"all recipes using butter"
SELECT r.name FROM recipeNeeds n
LEFT JOIN tableRecipes r
ON r.ID=n.recipeID
LEFT JOIN tableIngredients i
ON i.ID=n.ingredientID
WHERE i.name='butter'