How do I join three tables having the same primary key and make one view ? Any leads would be appreciated.
I have 3 tables sttm_customer, sttm_customer_c and sttm_customer_custom,
that have customer_no in common with all.
I need to make one view STVW_CUSTOMER_TEMP merging all of them.
If I understand what you're trying to do, you can use UNION:
SELECT customer_no (and any other matching columns)
FROM sttm_customer
UNION
SELECT customer_no (and any other matching columns)
FROM sttm_customer_c
UNION customer_no (and any other matching columns)
FROM sttm_customer_custom
Related
I am trying to join two tables together using UNION (although im not sure that is the best option) there are technically two related columns however they don't have the same name so i'm assuming that isn't an option here is my query:
SELECT title, type, release_date FROM pictures
UNION
SELECT name, residence, NULL as Col3 FROM actor
ORDER BY release_date ASC;
It is only printing out the pictures columns from this? Thank you for any help in advance.
To relate two tables you could use some foreign key or a third table in the case of beign a many-to-many relation, you should use one of the join options, for example:
Imagine that exists a table that relate actor and pictures, called actor_pictures.
Image that we will relate the tables by id (it could be another one, and it doesn't have to have the same name).
You could do this:
SELECT * FROM actor_pictures ap
JOIN actor a ON ap.actor_id = a.id
JOIN pictures p ON ap.pictures_id = p.id
ORDER BY p.release_date ASC
Read this: https://www.w3schools.com/sql/sql_join.asp
I have two tables of world countries Independence Day and I wanted to combine them into one table with a distinct id, but they are using different Primary keys, any suggestions will be appreciated.
Summary of request: How to combine two tables with different Primary Keys but the other fields in common and removing duplicate fields ideally Hash Match and removing duplicates
Expected Results this will include all the unique countries in both tables, please one table may have more countries and we want to make sure we take all the distinct countries from each table. Ideally, the solution will be likely to be of like Hash Match operator in SQL which implements several different logical operations that all use an in-memory hash table for finding matching data. Many thanks in advance
The image of two tables which needs combining.
You seem to want full join:
select a.*, b.* -- select the columns you want
from a full join
b
on a.country = b.country;
If you want to assign a new unique id use row_number():
select row_number() over (order by coalesce(a.country, b.country)) as new_id,
a.*, b.* -- select the columns you want
from a full join
b
on a.country = b.country;
I want to join two tables with different primary key values as below
Table A
id name
1 John
2 Smith
and Table B
id name
1-x Foo
2-x Bar
I've tried using LIKE statements on my query but it won't stop executing.
SELECT * FROM A a JOIN B b ON a.id LIKE b.id +'%'
Is there any efficient way to JOIN these two tables?
If you use a query like this:
SELECT *
FROM A a JOIN
B b
ON a.id || '-x' = b.id;
Then SQLite should be able to use an index on B(id) for the query. It is worth a try.
No, there's no efficient way of joining them.
That doesn't mean it cannot be done (it can), but it probably doesn't make sense.
Primary keys are not supposed to be good looking or sexy. They are unique row identifiers. If you have a primary key with a value like that, it's because you probably want to expose it or display it somewhere; and that's not their goal.
If you need a nice looking row identifier I suggest you create a secondary unique column that could even be auto-generated.
Bottom line, keep the primary key simple.
I have to two tables, both have a composite primary key:
OrderNr + CustNr
OrderNr + ItemNr
Can I join both tables with the OrderNr and OrderNr which is each a part of a composite primary key?
Yes, but you may find you get rows from each table that repeat as they combine to make a unique combination. This is called a Cartesian product
Table A
OrderNr, CustNr
1,C1
1,C2
2,C1
2,C2
TableB
OrderNr,ItemNr
1,i1
1,i2
SELECT * FROM a JOIN b ON a.OrderNr = b.OrderNr
1,C1,1,i1
1,C1,1,i2
1,C2,1,i1
1,C2,1,i2
This happens because composite primary keys can contain repeated elements so long as the combination of elements is unique. Joining on only one part of the PK, and that part being an element that is repeated (my custnr 1 repeats twice in each table, even though the itemnr and CustNr mean the rows are unique) results in a multiplied resultset - 2 rows from A that are custnr 1, multiplied by 2 rows from B that are custnr 1, gives 4 rows in total
Does it work with the normal/naturla join too?
Normal joins (INNER, LEFT OUTER, RIGHT OUTER, FULL OUTER) will join the rows from two tables or subqueries when the ON condition is valid. The clause in the ON is like a WHERE clause, yes - in that it represents a statement that is true or false (a predicate). If the statement is true, the rows are joined. You don't even have to make it about data from the tables - you can even say a JOIN b ON 1=1 and every rows from A will get joined to every row from B. As commented, primary keys aren't involved in JOINS at all, though primary keys often rely on indexes and those indexes may be used to speed up a join, but they aren't vital to it.
Other joins (CROSS, NATURAL..) exist; a CROSS join is like the 1=1 example above, you don't specify an ON, every row from A is joined to every row from B, by design. NATURAL JOIN is one to avoid using, IMHO - the database will look for column names that are the same in both tables and join on them. The problem is that things can stop working in future if someone adds a column with the same name but different content/meaning to the two tables. No serious production system I've ever come across has used NATURAL join. You can get away with some typing if your columns to join on are named the same, with USING - SELECT * FROM a JOIN b USING (col) - here both A and B have a column called col. USING has some advantages, especially over NATURAL join, in that it doesn't fall apart if another column of the same name as an existing one but it has some detractors too - you can't say USING(col) AND .... Most people just stick to writing ON, and forget USING
NATURAL join also does NOT use primary keys. There is no join style (that I know of) that will look at a foreign key relationship between two tables and use that as the join condition
And then is it true that if I try to join Primary key and foreign key of two tables, that it works like a "where" command?
Hard to understand what you mean by this, but if you mean that A JOIN B ON A.primarykey = B.primary_key_in_a then it'll work out, sure. If you mean A CROSS JOIN B WHERE A.primarykey = B.primary_key_in_a then that will also work, but it's something I'd definitely avoid - no one writes SQLs this way, and the general favoring is to drop use of WHERE to create joining conditions (you do still see people writing the old school way of FROM a,b WHERE a.col=b.col but it's also heavily discouraged), and put them in the ON instead
So, in summary:
SELECT * FROM a JOIN b ON a.col1 = b.col2
Joins all rows from a with all rows from b, where the values in col1 equal the values in col2. No primary keys are needed for any of this to work out
You can join any table if there is/are logical relationship between them
select *
from t1
JOIN t2
on t1.ORderNr = t2.OrderNr
Although if OrderNr cannot provide unicity between tables by itself, your data will be multiplied.
Lets say that you have 2 OrderNr with value 1 on t1 and 5 OrderNr with value 1 on t2, when you join them, you will get 2 x 5 = 10 records.
Your data model is similar to a problem commonly referred to as a "fan trap". (If you had an "order" table keyed solely by OrderNr if would exactly be a fan trap).
Either way, it's the same problem -- the relationship between Order/Customers and Order/Items is ambiguous. You cannot tell which customers ordered which items.
It is technically possible to join these tables -- you can join on any columns regardless of whether they are key columns or not. The problem is that your results will probably not make sense, unless you have more conditions and other tables that you are not telling us about.
For example, a simple join just on t1.OrderNr = t2.OrderNr will return rows indicating every customer related to the order has ordered every item related to the order. If that is what you want, you have no problem here.
I have table with the folowing columns:
row_id, customer_id, worker_id, vehicle_id, task_id, subcontractor_id.
I need to get the folowing data:
row_id, customer_name, worker_name, vehicle_name, task_serial, subcontractor_name
I can do this using simple inner joins for each table (Customers, Workers etc.) But each table is really huge (a lot of rows and each row has many fields), and I know that *_id (customer_id, worker_id, ..) is the primary key of its table.
Is there a way I can get this data and avoid many inner joins?
(maybe something with the foreign key, primary key or something like this..)
thanks
I think you will have to use joins - and it is not bad at all.
If the *_id columns are indexed (and primary keys are ususally indexed) it doesn't matter that the join tables are huge as the query processor will use the index to find the correct rows in the join tables - and not do a full table scan. The "many columns" should also be no problem for your query processor...
So I think the query will look something like this:
SELECT a.row_id, customer_name, worker_name, vehicle_name, task_serial, subcontractor_name
FROM my_table as a
INNER JOIN CUSOMER as b ON a.customer_id = b.customer_id
INNER JOIN WORKER as c ON a.worker_id = c.worker_id
...
Of course you can use Left koins as well.