I have a MySQL table named companies like this:
+---------+-----------+-----------+
| id_comp | comp_name | id_parent |
+---------+-----------+-----------+
| 1 | comp1 | NULL |
| 2 | comp2 | 1 |
| 3 | comp3 | 2 |
| 4 | comp4 | 2 |
| 5 | comp5 | 2 |
| 6 | comp6 | 1 |
| 3 | comp3 | 6 |
| 5 | comp5 | 6 |
| 7 | comp7 | 6 |
| 4 | comp4 | 6 |
| 8 | comp8 | 4 |
+---------+-----------+-----------+
Each company may have multiple parents (ex: comp3, which is child of comp2 and comp6), each parent may have multiple childs and each child can be a parent itself of multiple childs and so on... So, it can have unlimited levels (relations).
I researched several solutions (http://www.codeproject.com/Articles/818694/SQL-queries-to-manage-hierarchical-or-parent-child, http://mikehillyer.com/articles/managing-hierarchical-data-in-mysql/), but I don't think it fits my the problem since the same company (based on id_comp column) can have multiple parents.
I have two questions regarding this:
Is this the right approach if I have thousands of relations (scalable) ?
How do I, given a name (which is unique, based on id_comp) query to select its brothers (same parent_id), its direct parent(s), and its direct child(s).
You have a simple "many:many" relationship. However, you have a restriction that is not really relevant (nor checkable) in that there are no loops.
CREATE TABLE Relations (
id_comp ...,
id_parent ...,
PRIMARY KEY(id_comp, id_parent), -- for reaching "up"
INDEX(id_parent, id_comp) -- for reaching "down"
) ENGINE=InnoDB;
This will scale to millions, probably billions, of relations. Since a PRIMARY KEY is, by definition, UNIQUE and an INDEX, it prevents duplicate relations (1 is a parent of 2 only once) and provides an efficient way to traverse one direction.
Use DISTINCT instead of GROUP BY when necessary. Do not use IN ( SELECT ...), it tends to be slow.
My Siblings:
SELECT DISTINCT their_kids.*
FROM Relations AS me
JOIN Relations AS my_parents ON my_parents.id_comp = me.id_parent
JOIN Relations AS their_kids ON their_kids.id_parent = parents.id_comp
WHERE me.id_comp = #me
AND their_kids.id_comp != #me;
My (immediate) Parents:
SELECT my_parents.*
FROM Relations AS me
JOIN Relations AS my_parents ON my_parents.id_comp = me.id_parent
WHERE me.id_comp = #me;
My (immediate) Children:
SELECT my_kids.*
FROM Relations AS me
JOIN Relations AS my_kids ON my_kids.id_parent = me.id_comp
WHERE me.id_comp = #me;
Aunts, uncles, first cousins would be a bit messier. All ancestors or descendants would be much messier, and should be done with a loop in application code or a Stored Procedure.
Mysql isn't the best choice if you need to work with hierarchical data (getting all ancestors/descendants can be tricky). But if all you care about is finding direct parents/children, your table should be fine (although I might break it out into separate Company and CompanyParent tables so that the company name isn't entered multiple times).
This would give you brothers:
select name
from companies
where id_parent in (select id_parent from companies where id_comp = #company_id)
and id_comp <> #company_id
group by name;
This would give you direct parents:
select p.name
from companies p
join companies c on p.id = c.id_parent
where c.id_comp = #company_id
group by c.name;
This would give you direct children:
select c.name
from companies p
join companies c on p.id = c.id_parent
where p.id_comp = #company_id
group by c.name;
Related
I have two tables. The first one (item) is listing apartments. The second (feature) is a list of features that an apartment could have. Currently we list about 25 different features.
As every apartment can have a different set of features, I think it makes sense to have a 1:1 relationship between items and features table.
If in feature table for one the features the value is '1', this means that the linked apartment has this feature.
+-------------+------------+--------------+-------------+------------+
| table: item | | | | |
+-------------+------------+--------------+-------------+------------+
| id | created_by | titel | description | address |
+-------------+------------+--------------+-------------+------------+
| 10 | user.id | Nice Flat | text | address.id |
+-------------+------------+--------------+-------------+------------+
| 20 | user.id | Another Flat | text | address.id |
+-------------+------------+--------------+-------------+------------+
| 30 | user.id | Bungalow | text | address.id |
+-------------+------------+--------------+-------------+------------+
| 40 | user.id | Apartment | text | address.id |
+-------------+------------+--------------+-------------+------------+
+----------------+---------+--------------+----------------+--------------+------+
| table: feature | | | | | |
+----------------+---------+--------------+----------------+--------------+------+
| id | item_id | key_provided | security_alarm | water_supply | lift |
+----------------+---------+--------------+----------------+--------------+------+
| 1 | 10 | 1 | 0 | 0 | 1 |
+----------------+---------+--------------+----------------+--------------+------+
| 2 | 20 | 0 | 1 | 1 | 0 |
+----------------+---------+--------------+----------------+--------------+------+
| 3 | 30 | 1 | 1 | 0 | 1 |
+----------------+---------+--------------+----------------+--------------+------+
| 4 | 40 | 1 | 1 | 1 | 1 |
+----------------+---------+--------------+----------------+--------------+------+
I want to build a filter functionality so user can select to show only apartments with certain features.
e.g.:
$key_provided = 1;
$security_alarm = 1;
$water_supply = 0;
Does this database approach sounds reasonable for you?
What’s the best way to build a MySQL query to retrieve only apartments where the filter criteria match, keeping in mind that the number of features can be grow in future?
A better approach is to have a features table. In your case, they all seem to be binary -- yes or no -- so you can get away with:
create table item_features (
item_feature_id int auto_increment primary key,
item_id int not null,
feature varchar(255)
foreign key item_id references items(item_id)
);
The data would then have the positive features, so the first item would be:
insert into item_features (item_id, feature)
values (1, 'key_provided'), (1, 'lift');
This makes it easy to manage the features, particularly adding new ones. You might want to use a trigger, check constraint, or reference table to validate the feature names themselves, but I don't want to stray too far from your question.
Then checking for features is a little more complicated, but not that much more so. One method is explicitly using exists and not exists for each desired/undesired one:
select i.*
from items i
where exists (select 1
from item_features itf
where itf.item_id = i.item_id and
itf.feature = 'key_provided'
) and
exists (select 1
from item_features itf
where itf.item_id = i.item_id and
itf.feature = 'security_alarm'
) and
not exists (select 1
from item_features itf
where itf.item_id = i.item_id and
itf.feature = 'water supply'
);
For your existing data structure, you can filter as follows:
select i.*
from item i
inner join feature f
on f.item_id = i.id
and f.key_provided = 1
and f.security_alarm = 1
and f.water_supply = 0
This will give you all the apartments that satisfy the given criteria. For more criterias, you can just add more conditions to the on part of the join.
As a general comment about your design:
since you are creating a 1-1 relationship between apartments and features, you might as well consider having a single table to store them (spreading the information over two tables does not have any obvious advantages)
your design is OK as long as features do not change too often, since, basically, everytime a new feature is created, you need to add more columns to your table. If features are added (or removed) frequently, this can become heavy to manage; in that case, you could consider having a separated table where each (item, feature) tuple is stored in a different row, which will make this of things easier to do (with the downside that queries will get more complicated to write)
I'm struggling with creating a query to fetch data from several tables.
These are the tables:-
I want to query the base table, along with the others, to end up with these rows:-
So, the base table make_ID value needs to reference the makes table to populate the make column in the results. This bit I've managed to do with this query:-
SELECT code, make, Model_ID, time
FROM makes
INNER JOIN base
ON makes.ID = base.make_ID;
But the model column I'm finding tricky, as I need to get the result from make, and use that to choose the right table to get the model. So, looking at the first row, I would need to take the make result, which is brillo, and then use this to reference the brillo table using the id from model_ID, to get finepad.
How can I expand my query to do this? Any insight would be greatly appreciated.
as Jerry said you need a table make_models like this
+---------------+---------+----------+------------+
| make_model_id | make_id | model_id | model |
+---------------+---------+----------+------------+
| 1 | 1 | 1 | finepad |
| 2 | 1 | 2 | harshpad |
| 3 | 2 | 1 | toothbrush |
| 4 | 2 | 2 | toothpaste |
| 5 | 3 | 1 | ovenchips |
| 6 | 3 | 2 | porkpie |
+---------------+---------+----------+------------+
^^ unique identifier
So in your base table instead of referencing model_id you can reference make_model_id which is unique so you can do your join the same way you did with makes table
SELECT code, make, Model_ID, time
FROM makes
INNER JOIN base
ON makes.ID = base.make_ID
INNER JOIN make_models
ON base.make_id = make_models.make_id
AND base.model_id = make_models.model_id;
OR:
INNER JOIN make_models
ON base.make_models_id = make_models.make_models_id ;
If you can't change your model you can create a subquery to build it on the fly. See how I assign the make_id based on id from the makes table
SELECT base.code, makes.make, make_models.model, base.time
FROM base
JOIN make
ON base.make_id = makes.id
JOIN ( SELECT 1 as make_id, model_id, model
FROM brillo
UNION ALL
SELECT 2 as make_id, model_id, model
FROM colgate
UNION ALL
SELECT 3 as make_id, model_id, model
FROM mccaine
) as make_models
ON base.make_id = make_models.make_id
AND base.model_id = make_models.model_id
How can I query multiple many-to-many relationships in the same result set?
I have two tables that I typically always LEFT JOIN for a standard result set:
tblPROJECTS-
id | jobnumber | jobname ...
--------------------------------------------------
1 | 1000 | Project X
2 | 2000 | Project Y
3 | 3000 | Project Z
tblTASKS-
id | tasknumber | jobnumber | taskname ...
--------------------------------------------------
1 | 10 | 1000 | Project X: Task 1
2 | 20 | 1000 | Project X: Task 2
3 | 30 | 2000 | Project Y: Task 1
Tasknumber is a GUID, independent of jobnumber, but will never be related to more than one job.
I LEFT JOIN tblTASKS on jobnumber, since not all projects will have tasks (yet)
But then I also have an owners table that defines 1-n users who own either the job as a whole or the individual tasks (or both). Each user can own multiple jobs and/or tasks. The original design of the DB spec'd that a single table be used.
tblOWNERS-
id | ownertype | ownerid | jobnumber | tasknumber ...
----------------------------------------------------------------
1 | 1 | 2 | 1000 |
2 | 1 | 4 | 1000 |
3 | 2 | 2 | | 10
An ownertype of 1 indicates the user owns the overall job.
An ownertype of 2 indicates the user owns the task within the job.
I have two queries that I'm trying to construct:
1) Return the job with all associates job owners, joined with all tasks for that job with all associated task owners.
jobnumber | jobowners | tasknumber | taskowners ...
1000 | 2,4,... | 10 | 2
2000 | | 20 | 4,6,8...
3000 | 4,5,6... | 30 |
2) Given an owner ID, return all the jobs and/or tasks they are associated with.
It's the multiple many-to-many from/to the same tables that has me stumped. Can I accomplish this? If so, am I looking for some sort of UNION or INTERSECT (what do I look up to learn)? Or, if not, what's the better schema for relationships like this that would allow for it?
TIA!
Generally, you need to place the foreign key in the many end of an ERD, so in this case you might have a field called 'ownerid' in the table 'tblPROJECTS', as well as having 'ownerid' in tblTASKS. Assuming then that all tasks have a job ID and an owner, and all projects also have an owner, you can use INNER JOINs:
SELECT P.jobnumber,T.tasknumber,O1.id AS taskowner,O2.id AS jobowner
FROM tblTASKS T
INNER JOIN tblPROJECTS P ON P.jobnumber=T.jobnumber
INNER JOIN tblOWNERS O1 ON O1.id=T.ownerid
INNER JOIN tblOWNERS O2 ON O2.id=P.ownerid
WHERE O1.id=1
This will not concatenate the jobowners and task owners as you have described, but will return a row for each, which you can then concatenate whilst processing the resultset.
Then just replace the WHERE clause as necessary to get the list of tasks for a given Job number...
WHERE P.jobnumber=1000
I previously got a great answer (thank you #Paul Spiegel) on removing records from a table whose string was contained at the end of another record. For example, removing 'Farm' when 'Animal Farm' existed) and grouped by a Client Field.
The problem is, in fact, a little more complex and spans three tables, I'd hoped I could extend the logic easily but it turns out to also be challenging (for me). Instead of one table with Client and Term, I have three tables:
Terms
Clients
Look-up-Table (LUT) where I store pairs of TermID and ClientID
I have made some progress since initially posting this question so where I stand is I made the Joins and resultant Select return the fields I want to delete from the Look-up-Table (LUT):
http://sqlfiddle.com/#!9/479c72/45
The final select being:
Select Distinct(C.Title),T2.Term From LUT L
Inner Join Terms T
On L.TermID=T.ID
Inner Join Terms T2
On T.Term Like Concat('% ', T2.Term)
Inner Join Clients C
On C.ID=L.ClientID;
I am in the process of trying to turn this into a Delete with little success.
Append this to your query:
Inner Join LUT L2
On L2.ClientID = L.ClientID
And L2.TermID = T2.ID
That will ensure, that the clients do match and you will get the following result:
| ClientID | TermID | ID | Term | ID | Term | ID | Title | ClientID | TermID |
|----------|--------|----|---------------|----|-----------|----|-------|----------|--------|
| 1 | 2 | 2 | Small Dog | 1 | Dog | 1 | Bob | 1 | 1 |
| 2 | 5 | 5 | Big Black Dog | 3 | Black Dog | 2 | Alice | 2 | 3 |
To delete the corresponding rows from the LUT table, replace Select * with Delete L2.
But deleting the terms is more tricky. Since it's a many-to-many relation, the term may belong to multiple clients. So you can't just delete them. You will need to cleanup up the table in a second statement. That can be done with the following statement:
Delete T
From Terms T
Left Join LUT L
On L.TermID = T.ID
Where L.TermID Is Null
Demo: http://sqlfiddle.com/#!9/b17659/1
Note that in this case the term Medium Dog will also be deleted, since it doesn't belong to any client.
Each row in Table_1 needs to have a relationship with one or more rows that might come from any number of other tables in the database (Table_X). So I set up an intermediate table (Table_2) where each row contains an id from Table_1, and the id from Table_X. It also has its own auto increment id since none of the relationships will be exclusive and therefore both the other ids will not be unique in the table.
My problem now is that when I retrieve the row from Table_1 and would like to see the information from each related row from Table_X, I don't know how to get it. At first I thought I could create a column for the exact name of Table_X for each row in Table_2 and have a second SELECT statement using that information, but I've been seeing inklings about things such as foreign keys and join statements that I think I need to get into. I'm just having trouble sorting it all out. Do I even need Table_2?
This probably isn't overly complicated, but I'm just getting into MySQL and this is the first real challenge I've encountered.
Edit to include requested information: If I understand correctly, I think I'm dealing with a many to many relationship. Table_3 has games; Table_1 has articles. An article can be about multiple games, and a game can also have multiple articles written about it. The only other possibly pertinent information I can see is that when a new article is made, every game that will be related to it is decided all at once. But the list of articles related to a given game can grow over time as more articles are written. That's probably not especially important, however.
If I understood correctly You are talking about one to many relationship in database (for example: one person can have multiple phone numbers), You can store data in two separate tables persons and phones.
Persons:
|person_id|person_name |person_age |
| 1 | Bodan Kustan| 28 |
Phones:
|phone_id |person_id |phone_number|
| 1 | 1 | 31337 |
| 2 | 1 | 370 |
Then you can execute query with Join:
SELLECT * FROM `persons`
LEFT JOIN `phones` ON `persons`.`person_id` = `phones`.`person_id`
WHERE `persons`.`person_id` = 1;
And it will return to You list of persons with phone numbers:
|person_id|person_name |person_age |phone_id |person_id |phone_number|
| 1 | Bodan Kustan| 28 | 1 | 1 | 31337 |
| 1 | Bodan Kustan| 28 | 2 | 1 | 370 |
Another possibility is Many to Many relationship (for example: Any person can love pizza, and pizza is not unique for that person), then You need third table to join tables together person_food
Persons:
|person_id|person_name |person_age |
| 1 | Bodan Kustan| 28 |
Food:
|food_id |food_name |
| 1 | meat |
| 2 | pizza |
Person_Food
|person_id |food_id |
| 1 | 2 |
Then you can execute query with Join:
SELLECT * FROM `persons`
LEFT JOIN `person_food` ON `person`.`person_id` = `person_food`.`person_id`
LEFT JOIN `food` ON `food`.`food_id` = `person_food`.`food_id`
WHERE `persons`.`person_id` = 1;
And it will return data from all tables:
|person_id|person_name |person_age |person_id |food_id |food_name |
| 1 | Bodan Kustan| 28 | 1 | 2 | pizza |
However sometimes you need to join n amount of tables to join, then You could use separate table to hold information about relation. My approach (I don't think it's the best) would be to store table name next to relation (for example split mobile phones and home phones into two separate tables):
Persons:
|person_id|person_name |person_age |
| 1 | Bodan Kustan| 28 |
Mobile_Phone:
|mobile_phone_id |mobile_phone_number |
| 1 | 31337 |
Home_Phone:
|home_phone_id |home_phone_number |
| 1 | 370 |
Person_Phone:
|person_id |related_id |related_column |related_table |
| 1 | 1 | mobile_phone_id | mobile_phone |
| 1 | 1 | home_phone_id | home_phone |
Then query middle table to get all relations:
SELECT * FROM person_phone WHERE person_id = 1
Then build dynamic query (pseudo code, not tested -- might not work):
foreach (results as result)
append_to_final_sql = "LEFT JOIN {related_table}
ON {related_table}.{related_column} = `person_phone`.`related_id`
AND `person_phone`.`related_table` = {related_table}"
final_sql = "SELECT * FROM `persons` "
+ append_to_final_sql +
" WHERE `persons`.`person_id` = 1"
So Your final SQL would be:
SELECT * FROM `persons`
LEFT JOIN `person_phone` ON `person_phone`.`person_id` = `person`.`person_id`
LEFT JOIN `mobile_phone` ON `mobile_phone`.`mobile_phone_id` = `person_phone`.`related_id` AND `person_phone`.`related_table` = 'mobile_phone'
LEFT JOIN `home_phone` ON `home_phone`.`home_phone_id` = `person_phone`.`related_id` AND `person_phone`.`related_table` = 'home_phone'
You only need Table2 if entries in Table_x can be related to multiple rows in Table1 - otherwise a simple key for Table1 will suffice.
Look into joins - very powerful, flexible and fast.
select * from Table1 left join Table2 on Table1_id = Table2_table_1_id
left join Table_X on Tablex_id = Table2_table_x_id
Look at the output and you'll see that it returns all table_x rows with copies of the Table1 and Table2 fields.