I have two queries in MS Access. One has a field labeled "Assembly" and the other query has it's field labeled "Assemblies".
I need to compare the two queries (both with only the one column) and find out from the query with the "Assemblies" column which entries MATCH the other query.
Thanks
To find the matching records, a simple inner join will suffice here, e.g.:
select * from query1 inner join query2 on query1.assembly = query2.assemblies
Rename query1 & query2 as appropriate.
Related
I have an existing query (Query1) that returns 5 fields from a table. What I want to do is then have another query (Query2) that uses each record from one of the fields returned in Query1 to return fields from a different table. Both tables have a common field (Project). Query1 returns Project and 4 additional fields. For each record returned by Query1 I want to run Query2 based on the Project field. How do I design Query2?
Thanks in advance for your help!
Since both tables share a common field (Project), you should be able to JOIN them in a single query without having to worry about subqueries. Something like this:
SELECT *
FROM Table2
INNER JOIN Table1 ON Table2.Project = Table1.Project;
However, if Query1 is performing a specific operation to only return those 5 records, then you can just JOIN the results of Query1 to that other table. So your Query2 might look like:
SELECT *
FROM Table2
INNER JOIN Query1 ON Table2.Project = Query1.Project;
how do you convert a join query into a nested query (using "where in" condition)?
for eg how to convert this into a nested query?
SELECT student.studentname,
schedule.subcode,
AVG(attendance.ispresent)*100 AS Attendance_Status
FROM student
JOIN attendance
ON student.usn = attendance.usn
JOIN schedule
ON schedule.sched_id = attendance.sched_id
WHERE student.usn="4jc14is008"
GROUP BY schedule.subcode
ORDER BY schedule.subcode;
This will be evaluated as an NLJ ("Nested Loop Join").
Look in student, filtering on usn = '...'.
For each such row (probably one in this case), do NLJ into attendance to locate any and all rows that satisfy the ON given. This leads to a longer (or shorter) list of rows.
For each of the rows in #2, do NLJ into schedule based on ON. Now there is a set of rows...
Do the GROUP BY and ORDER BY (these can be done simultaneously since they are identical). This will deliver no more rows than what #3 gave. (GROUP BY can never increase the number of rows.)
Do not rewire the query into WHERE x IN ( SELECT ... ), that usually make it run slower.
I am refreshing my SQL.
I was reading about subqueries and the possibility to reference outside with correlated subqueries.
Example:
SELECT *
FROM ORDERS O
WHERE 'ROAD BIKE' =
(SELECT DESCRIPTION FROM PART P WHERE P.PARTNUM = O.PARTNUM)
This is equivalent with a join:
SELECT O.ORDEREDON, O.NAME,
O.PARTNUM, O.QUANTITY, O.REMARKS
FROM ORDERS O, PART P
WHERE P.PARTNUM = O.PARTNUM AND P.DESCRIPTION = 'ROAD BIKE'
My problem is that I didn't get the first form and when/why we use it. When are outside referenced queries useful?
Orders have a reference to the part number, so the Orders table has a foreign key to the part numbers.
We want all the Orders where the part number is for "Road Bike".
The first form first does a sub-query on every record, to check if O.PARTNUM is a part number for "Road Bike".
The way to think of it is, the main query is going through every record in the Orders table. On each record, it does a sub query, where it's PARTNUM field is used in the query. So, if you use the Orders record's PARTNUM in the sub-query, select to find the record in the PART table with that PARTNUM, and select the DESCRIPTION field. Then the where clause of the main query is check if "Road Bike" equals the DESCRIPTION returned from the sub-query.
I would recommend against using the first form, as it is a correlated query, and you should avoid correlated queries for performance reasons, so use the second form. A better version of the first form is:
SELECT *
FROM ORDERS O
WHERE O.PARTNUM =
(SELECT P.PARTNUM FROM PART P WHERE DESCRIPTION = 'ROAD BIKE')
This is not a correlated query. The database can do the subquery once, get the PARTNUM for the record with "ROAD BIKE" as the DESCRIPTION, and then run the main query with the condition WHERE O.PARTNUM equals the result of the sub-query.
In short, you should avoid correlated subqueries like the plague.
Correlated subqueries execute the inner query once for every row in the outer table. This results in terrible performance (a 1 million row outer table will result in the inner query executing 1 million times!)
A join on the other hand is quite efficient and databases are very good at optimising them.
If possible, always express your query as a join in preference to a correlated subquery.
A scenario where a subquery might be appropriate is something like this:
select some fields
from some tables
where some conditions are met
and somefield = (select min(something) from etc)
However, I don't know if that's a correlated subquery. Semantics aren't my strong point.
I came across the following SQL statement and I was wondering if it was valid:
SELECT COUNT(*)
FROM
registration_waitinglist,
registration_registrationprofile
WHERE
registration_registrationprofile.activation_key = "ALREADY_ACTIVATED"
What does the two tables separated by a comma mean?
When you SELECT data from multiple tables you obtain the Cartesian Product of all the tuples from these tables. It can be illustrated in the following way:
This means you get each row from the first table paired with all the rows from the second table. Most of the time, it is not what you want. If you really want it, then it's clearer to use the CROSS JOIN notation:
SELECT * FROM A CROSS JOIN B;
In this context, it means that you are going to be joining every row from registration_waitinglist to every row in registration_registrationprofile
It's called a cartesian join
That query is 'syntactically' correct, meaning it will run. What the query will return is the entire product of every row in registration_waitinglist x registration_registrationprofile.
For example, if there were 2 rows in waitinglist and 3 rows in profile, then 6 rows will be returned.
From a practical matter, this is almost always a logical error and not intended. With rare exception, there should be either join criteria or criteria in the where clause.
I need to select records from 2 tables, one called cities and one called neighborhoods. They both share a table column in common called parent_state. In this cell the id of the parent state is stored.
I need to select all cities and neighborhoods that belong to a certain state. For example if the state id is 10, I need to get all the cities and neighborhoods that has this value for it's parent_state cell.
The state id is stored in a PHP variable like so:
$parent_state = '10';
What would this query look like (preferably the merged results from both tables should be sorted by the column name in alphabetical order)?
EDIT
Yes, I probably do need a union. I'm very new to mysql and all I can do at the moment is query tables individually.
I can always query both the cities and neighborhoods tables individually but the reason why I want to merge the results is for the sole purpose of listing said results alphabetically.
So can someone please show how the UNION query for this would look?
Use:
SELECT c.name
FROM CITIES c
WHERE c.parent_state = 10
UNION ALL
SELECT n.name
FROM NEIGHBORHOODS h
WHERE n.parent_state = 10
UNION ALL will return the result set as a combination of both queries as a single result set. UNION will remove duplicates, and is slower for it - this is why UNION ALL is a better choice, even if it's unlikely to have a city & neighbourhood with the same name. Honestly, doesn't sound like a good idea mixing the two, because a neighbourhood is part of a city...
Something else to be aware of with UNION is that there needs to be the same number of columns in the SELECT clause for all the queries being UNION'd (this goes for UNION and UNION ALL). IE: You'll get an error if the first query has three columns in the SELECT clause and the second query only had two.
Also, the data types have to match -- that means not returning a DATE/TIME data type in the same position was an other query returning an INTEGER.
What you want is probably not a join, but rather, a union. note that a union can only select the exact same columns from both of the joined expressions.
select * from city as c
inner join neighborhoods as n
on n.parent_state = c.parent_state
where c.parent_state=10
You can use Left,Right Join, in case of city and nighborhoods dont have relational data.