Hi I have a division_Type table
Division_ID || Division_Area || Parent_ID
1 Central_Level
2 Provincial 1 // Provinvial Parent_ID is Central_level
3 District 2 // District Parent_ID is Provincial
4 MOH 3
5 PHI 4
And I have a Division_Details Table
Division_Det_ID || Div_Name || Division_Type_ID || Parent_ID
1 Western 2
2 Eastern 2
3 Colombo 3 1 //Colombo Parent ID is Western ID
4 Nugegoda 4 3 //Nugegoda Parent_ID is Colombo ID
5 Udahamulla 5 4
6 Gampaha 5 4
7 Negambo 5 2
Hi I have two tables named Division_Details and division_Type. Division_ID is the foreign key of Division_Type_ID. In the Example Division_Details Table Parent_ID is the Parent ID(Division where the lower level division belongs to) of Each Division. I may need to find the PHI areas belongs to Colombo district. That's why I told this is a dynamic query.
Please someone give even a doc for me to refer. As I haven't any idea about this thing.
I'm getting the ID(Division_Det_ID) of Western. What I need to find out is what is the PHI area of Western.
Well I need to write a dynamic query. I have no any idea to to go this more further. As u can see in the Division_Details table Udahamulla, Negambo, Gampaha are PHI areas. Among them Udahamulla and Gampaha are PHI areas of Western. So I need to get the IDs of these PHI areas as it belongs to the Western Province.
Edited:
If I select PHI in the first text box, result in the second select box should be Udahamulla, Gampaha, Nugambo. In the sorting text box when Western is selected only Udahamulla and Gampaha should be shown. Since Negambo is in Eastern Province.
Related
Lets say I have two tables, and in this example, the fish table has Place as a foreign key. In a select statement, how can I get the average weight per place, but instead of showing the id, it shows either the name of the place or the country that has the same id.
Fish
ID Type Weigth Place
1 Cod 300 1
2 Pike 600 2
3 Pike 1000 2
4 Salmon 800 1
Place
ID Name Country
1 NY USA
2 London UK
3 Oslo Norway
I can only figure out how to get average weight per place and return the id, but not the name or country of the place. I think I need to use join of some sort, but cant figure out how.
Thanks in advance
I'm building a e-Commerce platform (PHP + MySQL) and I want to add a attribute (feature) to products, the ability to specify (enable/disable) the selling status for specific city.
Here are simplified tables:
cities
id name
==========
1 Roma
2 Berlin
3 Paris
4 London
products
id name cities
==================
1 TV 1,2,4
2 Phone 1,3,4
3 Book 1,2,3,4
4 Guitar 3
In this simple example is easy to query (using FIND_IN_SET or LIKE) to check the availability of product for specific city.
This is OK for 4 city in this example or even 100 cities but will be practical for a large number of cities and for very large number of products?
For better "performance" or better database design should I add another table to table to JOIN in query (productid, cityid, status) ?
availability
id productid cityid status
=============================
1 1 1 1
2 1 2 1
3 1 4 1
4 2 1 1
5 2 3 1
6 2 4 1
7 3 1 1
8 3 2 1
9 3 3 1
10 3 4 1
11 4 3 1
For better "performance" or better database design should I add
another table
YES definitely you should create another table to hold that information likewise you posted rather storing in , separated list which is against Normalization concept. Also, there is no way you can gain better performance when you try to JOIN and find out the details pf products available in which cities.
At any point in time if you want to get back a comma separated list like 1,2,4 of values then you can do a GROUP BY productid and use GROUP_CONCAT(cityid) to get the same.
Folks can you please give your suggestions for my question regarding mysql joins.
My Table structures:
place table:
place_id place_name city
1 Hotel Golconda Hyderabad
2 Paradise Hotel Hyderabad
3 Hotel Mayuri Hyderabad
place_tags
tag_id tag_name
1 Valet Parking
2 Air Conditioned
3 Buffet
4 Bar
5 Family Dining
places_info Table:
place_id tag_id
1 1
1 2
1 3
2 1
2 5
3 1
3 4
The above is all my tables which are containing the place names and address in places table, all the facilities of the restaurants in tags table and mapping of the facilities of each place in places_info table.
Is this my table structures are correct to get the places which had "Valet parking and Buffet". How can write a join query for this type of results to get.
Most Importantly we had millions of places in places table and also in the places_info table. How to achieve maximum performance with this type of table structure? Or shall I need to change the table structures?
Please guide me.
This'd be the basic structure for "places with valet AND buffet":
SELECT place_id, COUNT(places_info) AS cnt
FROM place
LEFT JOIN places_info ON place.place_id = places_info.place_ID
AND tag_id IN (1, 3)
^^^^---- two tags: valet(1) + buffet(3)
GROUP BY place.place_id
HAVING cnt = 2
^^^---- must have both tags
For a places which have NEITHER of the tags, or only one, the count would come back 0, or 1, and get dumped by the HAVING clause.
This question already has answers here:
Possible to do a MySQL foreign key to one of two possible tables?
(6 answers)
Closed 8 years ago.
I am fumbling my way through phpMyAdmin and mySQL. I’m creating something where a customer can register multiple products. The data coming in is:
Category > Type > Size > Color
So for example:
Cookware > Oven > 5 qt > Blue
Bakeware > Casserole > 3qt > Blue
Accessories > Textiles > N/A > Blue
Etc.
I have set up one table with categories, and 4 tables to cover each product type.
Categories
ID Category
1 Cookware
2 Bakeware
3 Accessories
4 Serveware
Cookware Table
ID Type
1 Oven
2 Skillet
3 Roaster
Bakeware Table
ID Type
1 Casserole
2 Pie Dish
3 Baker
Etc.
Then, in the registration table, I set up a foreign key to link the category to the category table. So it would look something like this:
ID CustID Category Type Size Color
1 20 2 1 11 34
1 20 1 1 9 34
(sorry the formatting is so terrible! not sure how to fix)
But, I’m stuck on how to link the product type to the correct product type table since it is dependent on which category they picked. Hopefully this makes sense. Maybe I don't even need to link them and can still request the data somehow through a query?
Merge the last 2 tables ?
ID Type Category
1 Oven 1
2 Skillet 1
3 Roaster 1
4 Casserole 2
5 Pie Dish 2
6 Baker 2
Supoose I have the following:
tbl_options
===========
id name
1 experience
2 languages
3 hourly_rate
tbl_option_attributes
=====================
id option_id name value
1 1 beginner 1
2 1 advanced 2
3 2 english 1
4 2 french 2
5 2 spanish 3
6 3 £10 p/h 10
7 3 £20 p/h 20
tbl_user_options
================
user_id option_id value
1 1 2
1 2 1
1 2 2
1 2 3
1 3 20
In the above example tbl_user_options stores option data for the user. We can store multiple entries for some options.
Now I wish to extend this, i.e. for "languages" I want the user to be able to specify their proficiency in a language (basic/intermediate/advanced). There will also be other fields that will have extended attributes.
So my question is, can these extended attributes be stored in the same table (tbl_user_options) or do I need to create more tables? Obviously if I put in a field "language_proficiency" it won't apply to the other fields. But this way I only have one user options table to manage. What do you think?
EDIT: This is what I propose
tbl_user_options
================
user_id option_id value lang_prof
1 1 2 null
1 2 1 2
1 2 2 3
1 2 3 3
1 3 20 null
My gut instinct would be to split the User/Language/Proficiency relationship out into its own tables. Even if you kept it in the same table with your other options, you'd need to write special code to handle the language case, so you might as well use a new table structure.
Unless your data model is in constant flux, I would rather have tbl_languages and tabl_user_languages tables to store those types of data:
tbl_languages
================
lang_id name
1 English
2 French
3 Spanish
tbl_user_languages
================
user_id lang_id proficiency hourly_rate
1 1 1 20
1 2 2 10
2 2 1 15
2 2 3 20
3 3 2 10
Designing a system that is "too generic" is a Turing tarpit trap for a relational SQL database. A document-based database is better suited to arbitrary key-value stores.
Excepting certain optimisations, your database model should match your domain model as closely as possible to minimise the object-relational impedance mismatch.
This design lets you display a sensible table of user language proficiencies and hourly rates with only two inner joins:
SELECT
ul.user_id,
u.name,
l.name,
ul.proficiency,
ul.hourly_rate
FROM tbl_user_languages ul
INNER JOIN tbl_languages l
ON l.lang_id = ul.lang_id
INNER JOIN tbl_users u
ON u.user_id = ul.user_id
ORDER BY
l.name, u.hour
Optionally you can split out a list of language proficiencies into a tbl_profiencies table, where 1 == Beginner, 2 == Advanced, 3 == Expert and join it onto tbl_user_languages.
i'm thinking it's a mistake to put "languages" as an option. while reading your text it seems to me that english is an option, and it might have an attribute from option_attributes.