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'
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...
Well im working on an online game project where every player will get to have a house, the project was going great until u had to organize houses thinking that i will have a limit of 10.000 players on the server.
so here are some facts:
each player may have up to 10 houses (min 1).
that means i need 100.000 possible houses so that no matter how full the server gets, there will always be 10 possible houses for each player.
there will be 20 cities, each city will have 200 neighborhoods, and each neighborhood will have 25 houses
so thats when the problem shows up, how would the database work?
whenever i want to see any of the 100.000 houses, it will belong to a neighborhood on a city, and i need to be able to play with that, like if i want to see house #5 of the neighborhood #123 city#8, then i should be able to get the data.
i was thinking about having one table with all 100.000 houses, and having values on that table to tell what neighborhood it is on what city, but it feels like there must be a better way. (maybe using multiple tables? i dont know)
so any help would be appreciated.
thank you for your time.
It's hard to answer, because your complete requirements aren't known.
But I'd recommend that you normalize the database - 3rd normal form at minimum. If you don't know what that is, I'd recommend learning about it ASAP.
My best guess is as follows:
PLAYER is one-to-many with HOUSE. If more than one PLAYER owns the same HOUSE, then it's many-to-many.
CITY is one to many with NEIGHBORHOOD
NEIGHBORHOOD is one-to-many with HOUSE
You'll do JOINS to associate a PLAYER with cities, neighborhoods, and houses. You should have surrogate primary keys on all tables and appropriate foreign keys. Add UNIQUE indexes on all other candidate key combinations.
Run EXPLAIN PLAN on all your queries to make sure that they don't require TABLE SCAN and perform adequately.
10,000 players isn't a big number for a database. You won't have any problem.
Here's what your query to select all the houses in a neighborhood might look like:
SELECT *
FROM HOUSE H
INNER JOIN NEIGHBORHOOD N
ON H.HOUSE_ID = N.HOUSE_ID
INNER JOIN CITY C
ON N.NEIGHBORHOOD_ID = C.NEIGHBORHOOD_ID
WHERE C.CITY_ID = 8
AND N.NEIGHBORHOOD_ID = 123
ORDER BY H.HOUSE_ID
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'm designing a simple database for a rental listings website,
sort of like classified ads but only for home/room rentals. This is what I've come up with thus far:
Question 1
For the "post" table, I actually wanted more information. For example, there would be a 'facilities' section where the users can select whether there's 'parking' available, do I need a separate table? Or just use 0 for no and 1 for yes?
Question 2
Here's what I did with the "category" table (sorry I don't know how to pretty print yet)
Category_ID 1 is Rent
Category_ID 2 is buildingType
For "categoryProperty" table
Category_ID 1 categoryPropertyID 1 House
Category_ID 1 categoryPropertyID 2 Room
Category_ID 2 categoryPropertyID 3 Apartment
Category_ID 2 categoryPropertyID 4 Condominium
Category_ID 2 categoryPropertyID 5 Detached
Does the above make sense?
Question 3
Users can post whether they are logged in or not. Just that logged in users/members have the advantage of tracking their ads/adjusting the availability.
How do I record the ads that a member has posted? Like their history.
Should I create a "postHistory" table and set the 'postHistory_ID' as FK to "member" table?
Thanks a lot in advance, I appreciate your help, especially just pointing me to the right direction.
Question 1:
make a separate table and make a One to One relation, that would be the simplest way:
POST -|-----|- EXTRAS
in EXTRAS you may have every extra field (parking=1/0, in_down_town=1/0,has_a_gost=1/0)
Question 2:
This does not make sense, you've two options:
in the Post table create a "type_of_operation", that can have two vales (building_type,rent). Or you can create different tables, but would make this more complicate (you should analyise if the same type can be in both states, etc).
Question 3:
I recommend you to make your users register. Even with a really simple form (email+password) .
Seems to be on the right track -- with respect to your specific questions:
Question #1: Assuming there's more than one type of facility (parking; swimming pool; gym) then you have a many-to-many relationship and you want 2 new tables: Facilities and PropertyFacilities. Each Property (or I guess "post") could have multiple rows in the PropertyFacilities table.
Question #2: Not really clear on what you're getting at -- is it that each property type can either be rented whole or rented per room?
Question #3: Good question, what you want to do is have an Active bit, or an ExpireDate, in your POST table -- then anything that becomes inactive or expired is automatically 'historical' data, no need to marshall it to a history table. Although you'll have to archive eventually of course.
I have 2 MySQL tables , each with address data of companies in it. One table is more recent, but has no telephone and no website data. Now I want to unite these tables into 1 recent and complete table.
But for some companies the order of the words is different,like this:
'Bakery Johnson' in table 1 and 'Johnson Bakery' in table 2.
Now I need to find a way to compare these values, as they're obviously the same company.
I think I will somehow have to split those names first, and then order the different parts alphabetically.
Any chance anybody has done something like this before, and willing to share some code or function?
UPDATE:
I found a function that sorts words inside a string. I can use this to detect name swaps as described above. It's quite SLOW though...
See : MySQL: how to sort the words in a string using a stored function?
If your table is MyISAM you can run this query:
SELECT *
FROM mytable
WHERE MATCH(name) AGAINST ('+bakery +johnson')
This will find all records containing the words bakery and johnson (and probably some other words too).
Creating a FULLTEXT index on the table:
CREATE FULLTEXT INDEX
fx_mytable_name
ON mytable (name)
will speed up this query.
Going back a bit on your solution, you could go with a similar way as modern phones resolve duplicate names conflicts
You present your user with the option, as he finds something suspicious:
Is this a duplicate? Use our [ Merge ] option
You are merging Bakery Johnson, please select the source/original item:
[ Johnson Bakery v ] (my amazing dropdown!)
Everything not already in Johnson Bakery gets ported to Bakery Johnson (orders for example), you may also show an intermediate screen displaying what will be merged, or let the user pick, for example, he wants the address info from Johnson Bakery and orders from both etc
It is not self correcting as you asked, but the collaboration from the users may be more accurate than AI here. I also love low-tech solutions like this so let us know what you ended up doing.