If I say:
A NATURALJOIN B
Is that the same as:
B NATURALJOIN A
Similarly, if I say:
A NATURALJOIN B NATURALJOIN C
How is that supposed to be evaluated?
Here are my remarks:
NATURALJOIN is two words: NATURAL JOIN
The order of the tables makes no difference. Exception: when you SELECT *, then the list of selected columns is all columns of the first table, then all columns of the second table.
Don't use NATURAL JOINs. It joins tables by their common columns. If the tables happen to share a column name like "text", "description" or "name" this will be used. Imagine you write a program with a SELECT statement, where two tables person and job are joined by person_id. Later you add a column "description" to both tables. Suddenly your program will fail completely to get any matching record, because "person_id" may match, but "description" won't.
Related
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 have several tables with a bunch of fields and I need a Query that includes ALL the fields from two tables (JOINs). The result should have consistent naming scheme for the fields, that survives when I add fields to the source table.
To always select all fields of a table I can use the * operator. But when I join two tables using the *, it prepends the fields that occur in both tables (and only those) with the table name.
SELECT kids.*, parents.* FROM parents INNER JOIN kids ON parents.ID = kids.ParentID;
gives me
kids.name, birthday, school, parents.name, address ...
When I add a birthday column to the parents table I get
kids.name, kids.birthday, school, parents.name, parents.birthday, address ...
And I have to update birthday to kids.birthday everywhere.
Is there a way to prepend all column names in the beginning?
So I'd get
kids.name, kids.birthday, kids.school, parents.name, parents.address ...
in the first place?
I am working on ABAP program - user input is to query column ANLAGE and output is to get all records from table EADZ (and only fields of EADZ) based on ANLAGE.
Statement and joins should work like this:
Input ANLAGE, find in table EASTL, gets LOGIKNR
Input LOGIKNR, find in table EGERR, gets EQUNR
Input EQUNR, find in table ETDZ, gets LOGIKZW
Input LOGIKZW, find in table EADZ, gets all records (this is the final output)
Here is the code I tried:
DATA: gt_cas_rezy TYPE STANDARD TABLE OF eadz,
lv_dummy_eanl LIKE eanl-anlage.
SELECT-OPTIONS: so_anl FOR lv_dummy_eanl NO INTERVALS NO-EXTENSION.
SELECT * FROM eadz
INNER JOIN etdz ON eadz~logikzw EQ etdz~logikzw
INNER JOIN egerr ON etdz~equnr EQ egerr~equnr
INNER JOIN eastl ON egerr~logiknr EQ eastl~logiknr
INTO CORRESPONDING FIELDS OF TABLE #gt_cas_rezy
WHERE eastl~anlage IN #so_anl.
I got the records from table EADZ except that the date fields are empty (even though, they are filled in database table). I am assuming there is a problem with JOINs since in statement like this I join all the fields of all 4 tables into one "record" and then to corresponding fields of internal table.
How to get the values of date fields?
You can find the answer in the documentation.
If a column name appears multiple times and no alternative column name was granted, the last column listed is assigned.
In your case, at least two tables share the same column name. Therefore the values from the last mentioned table are used in the join.
You can solve this by listing the columns explicitly (or eadz~* in your case), giving an alias if required.
SELECT EADZ~* FROM EADZ INNER JOIN ETDZ ON EADZ~LOGIKZW = ETDZ~LOGIKZW
INNER JOIN EGERR ON ETDZ~EQUNR = EGERR~EQUNR
INNER JOIN EASTL ON EGERR~LOGIKNR = EASTL~LOGIKNR
INTO CORRESPONDING FIELDS OF TABLE #gt_cas_rezy
WHERE EASTL~ANLAGE IN #SO_ANL.
If you require additional fields, you can add them explicily with e.g. EADZ~*, EASTL~A.
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.
Lets suppose that I have a table A with couple of columns. I work with tables, where there is no index on the entries, since they are 'historical' tables. I use one specific column, though, to sort of identify my things. Lets call this ID.
If you'd make a query like the one below, sometimes you'd get one line back, other cases a few.
SELECT * FROM A WHERE ID = '<something>'
Lets say I have two more tables, B and C. Both have ID columns, like A.
Also, some of the IDs in A, are also in B OR C. IDs existing in B CANNOT exist in C. And ALL IDs in A EXIST in either B OR C.
B and C contain extra information, which I'd like to join to A at the same SELECT.
My problem is, that they would only provide extra information. I do not want extra lines in my output..
To make it more clear: my selection from A returns a hundred lines of output.
When I left/right/inner join B table, I —probably— will have less lines as output. Same thing with joining C.
AND FINALLY, my question is:
Is there a way to join table B only on those IDs, which exist in B and vice versa? (And it I would want it in the same SELECT.... statement.)
If you don't want extra lines in your output, you could do something like this:
select *
from A join
(select B.*
from B
group by B.id
) B
on A.id = B.id;
This would choose arbitrary values from B for each id and join them back to A. Is this what you want?
Well it seems like you should build some left join between A and two "Select MAX"s: one from table B, the other one from table C.
And if you do not want 'duplicate' IDs from table A, a 'group by' on table A should help.