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
Related
I'm currently working on a game where we use ressources like: food, wood, stone, copper, etc. I'm having a problem with the structure for my ressources table.
A ressource has a: "name" and a "base price".
Each guild has a list of ressources (their personal banks of accumulated ressources).
Buildings have a cost of creation (a farm cost 10 woods and 2 stones to create).
Buildings have a monthly production (a farm produce 4 foods per month).
What is the best way to create my tables in this scenario?
First I went with a simple "Ressources" table with only 3 fields (id, name and basePrice).
Then I made an "Guild_has_ressource" table between "Ressources" and "Guild".
Then it became a mess when I tried to do the same with "Buildings"... There was gonna be way too many tables. There is gotta be an optimal way of doing this.
EDIT: Lotan mentionned I needed more details.
My database looks like this:
Database_v1
All my ressources are in a single table "Inventaires". I have a strong feeling that it is the wrong way of doing it.
I believe they should be in a table called "Ressources" where they can have their own "name" field and "basePrice".
A guild has ressources in its bank, a building has a construction price and a production income. How can all these 3 field connects to the same Table "Ressources"?
EDIT2: After more comments. I tested 2 more options.
1st: https://ibb.co/ZdHYLMT
2nd: https://ibb.co/G3ntdLz
What do you guys think? Am I in the right direction?
What I ended up doing is this
It does not feel right, it does not work properly but it's what I managed to do by myself...
So in my application database I have a business profile entity that has:
one main Category (e.g. Restaurant, Hotel, Hospital, ...etc)
unlimited Subcategories (e.g. pizza restaurant, Italian restaurant, ...etc)
unlimited products (e.g. cheese pizza, pepperoni pizza, ...etc)
unlimited services (e.g. pick-up service, delivery service, ...etc)
P.S. I went with the Restaurant category as an example to demonstration its subcategories/services/products entities, but, it could be any anything really.
First: I can use something like the Adjacency List Model to define unlimited categories and their corresponding subcategories but, what about services and products entities ? how can I link them all to each another knowing that services and products are children of the subcategory entity?
For now this is what I have:
Figure-1
Second: How can I map each Business profile with its Category/subcategories/products/services ?! so that I know each business profile is under what category and what are the subcategories/products/services that each business profile has.
Here is the mapping that I have at the moment:
Figure-2
I am yet a novice database designer, I'm trying to make this database to be as much efficient as possible, as it will receive a lot of traffic. Is what I have now valid as a database scheme or is there any database designing concepts that needs to be dig deeper?
When I read this question I was worried this was going to have a complicated tree structure, but reading your work so far it's very clean and simple.
Personally, I think you're on the right track, and would make a few notes:
It's not hard to link services and products to subcategories, and you can also easily link businesses and products/services. I don't think this needs to be a tree. Just enforce this restriction when the records are created.
Adjacency List Model makes a lot of sense for trees of arbitrary depth for which you need to easily find subtrees, but I'm not sure if that fits your problem, in particular because:
You don't have arbitrary depth. You just have parents and sub-categories.
For something like a business-category system, the number of entries might be low enough that it's not worth adding the extra complexity. It's probably pretty fast to read the entire table and keep it in memory.
If you want services and products linked to both subcategories and categories, the simplest might be to have a single category table and have each category have a parent_id that may be null.
I am designing a database for a website of selling houses and lands. I have an issue that is the house may be in one or many lands, and the land may contain one or many lands depends on its area.
I came up with initial design and the relation between the land and the house is many to many:
House:
Id - Name – area –landID – noRooms – hasSwimmingPool
Land:
Id – name – area - location
Offer: (contain the offer of either a land or a house)
Id – userID – type – paymentMethod
Land_House:
houseID – landID
I still cannot relate Land_House table to the offer table.
Is there a better approach than what I did? And what is the best way?
One aproach could be to have a superior Property table, and house and land could have their primary key as a foreign key to this table. This way you could keep the land house relationship with out mixing what a land and a house are on one table, since they are different things, then add the property id on the Offer table, that could be of a house or a land.
It's like thinking of inheritence .
Hope this helps.
To answer your first question, you missed the obvious; your Offer table has no field for Property. How are you going to store what they made an offer on? I would suggest putting in a column for OfferType and storing either H (House) or L (Land), and then adding PropertyID. This way you can join back to the proper ID in either House or Land, depending on the value of OfferType.
Ideally, though, House and Land would be one table with a field for PropertyType.
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'