|WikiProject Computing||(Rated C-class, Low-importance)|
|WikiProject Databases / Computer science||(Rated C-class, Mid-importance)|
New comments at the bottom of the page, please.
- 1 SemiJoins
- 2 Images for join types
- 3 Left Outer Join
- 4 Equi-Join Columns
- 5 Equi Joins
- 6 Implicit outer joins
- 7 Full outer joins by left joins
- 8 Foreign key error
- 9 Computation of Cartesian product
- 10 Full outer join emulations
- 11 About natural joins
- 12 MATHS?
- 13 Sentence doesn't make sense?
- 14 I Disagree with Reviewer's View that the Content Should Be Simplified
- 15 Additional Concern on Natural Joins from the Object Oriented Perspective
- 16 Making content accessible to a wider audience is not tantamount to "dumbing down."
- 17 Are the insert examples really necessary?
- 18 First mention of join
- 19 Motivation
- 20 Right outer join
- 21 Self join example
- 22 Joining more than two tables - Comments on Inner Joins
- 23 Natural Join section is unclear
- 24 implicit "OUTER" for LEFT JOIN?
- 25 Deleted
- 26 I found this article to be confusing
- 27 Please add a section about "LATERAL JOIN"
- 28 Natural join is described in two places now
- 29 Natural join does not have an SQL example
what about semijoins
- From the article:
- A semi join is an efficient join method where first the join attributed of one table are collected and reported to the second one. In was first reported in 1981. It can be improved with a Bloom-Filter (hashing).
- Yeah, it could do with a lot more detail. Neilc 13:59, 16 Apr 2005 (UTC)
- The problem with the current description for semi joins is that it doesn't say anything at all: How is something reported? What means "collect" in the above sentence? And how exactly would the improvement with hashing work? I think that we either expand this to something comprehensible or remove it. --Stolze 21:50, 14 April 2007 (UTC)
I removed the semi-join stuff from the article because it didn't say anything meaningful. --Stolze 11:52, 8 May 2007 (UTC)
Images for join types
It would be good if someone would add images to help people visualize how each type of join is evaluated. I'm thinking that there should be drawings with the overlapping rings, highlighting the solution set. I would be willing to create them, however, I do not have experience loading images into Wikipedia. DBBell 21:08, 14 December 2005 (UTC)
- I hope you don't mix this up with set operations like UNION, EXCEPT, and INTERSECT? If not, you could draw the images and we will incorporate them. --Stolze 12:19, 22 April 2007 (UTC)
A visual image might be to consider customers and orders. A left outer join would provide a set of all customers, whether or not the customer had any orders, PLUS the order records for those customers that had orders. It is possible that a customer might have no orders, so the business might want to delete him or her from the database, or send them a catalog.
A right outer join on the orders would be useful for that business to correct possible errors, since an order without a customer to pay for it would be a problem. This type of join would produce a set of records for all orders whether or not there was a customer related to it, PLUS the customer that ‘owns’ the order, so to speak.
In either type of outer join, it is only necessary to check for nulls in the related table to find ONLY those records that DO NOT have a related record in the related table.
Left Outer Join
Just a quick question. Was it neccasary to have a "select _distinct_ *" in the code example for left outer joins?
- It is not necessary. DISTINCT is a concept orthogonal to joins. Therefore, I removed this keyword.
For those of us who work daily with SQl but have to look up the definition of 'orthogonal', "select distinct" should be assumed to be a crutch to fix a problem that may be solved more efficiently by other changes. Some experts with more experience than me recommend searching for any code that uses 'select distinct' as a quick means of identifying SQL that should be worked on to improve system efficiency. — Preceding unsigned comment added by 220.127.116.11 (talk) 16:04, 11 August 2014 (UTC)
I believe this might be an error. From the article:
- The resulting joined table contains two columns named DepartmentID, one from table Employee and one from table Department.
If I'm not mistaken, this would be incorrect behavior under the SQL standard. I believe this is how it worked in earlier versions of MySQL, and possibly other DBMSs, but as per standard MySQL now only includes one instance of the join column.
Also, under Natural Joins, the order of the columns given may be incorrect (once again, possibly this is the actual order in some implementations). I believe the spec calls for the join columns to come first, and then the other columns of each table in turn.
I am basing this on the [MySQL docs], the part which begins:
- The columns of a NATURAL join or a USING join may be different from previously. Specifically, redundant output columns no longer appear, and the order of columns for SELECT * expansion may be different from before...
- You are correct, according to ISO/IEC 9075-2:2003 natural joins do suppress duplicate columns. This is from Section 7.7 (Syntax rules):
"7) If there is at least one corresponding join column, then let SLCC be a <select list> of <derived column>s of the form COALESCE ( TA.C, TB.C ) AS C for every column C that is a corresponding join column, taken in order of their ordinal positions in RT1."
It's stating that the resulting duplicate named column in the select list is the coalesced result from the columns of the same name in both table A and table B.SqlPac (talk) 05:51, 6 February 2008 (UTC)
It should be clearer what is meant by "A" and "B" in the article, i.e. which part of the sample query is the A table and which is the B table. (better yet, call the tables A and B to make it completely clear. —Preceding unsigned comment added by 18.104.22.168 (talk) 22:26, 19 March 2008 (UTC) Since SQL returns sets by default, the results would be DISTINCT because the duplicates cannot exist in a proper SET, as I understand it. Foresight2008 (talk) 03:42, 26 July 2008 (UTC) CL
The SQL standard deviates from the relational model in several ways even if it is supposed to be the standard language of relational databases, and all databases I know of deviate from the SQL standard. All DBMSs I know of will NOT allow you to create a table where multiple columns have the same name like "CREATE TABLE bad (col INT, col INT);" but most WILL let you run a query that results in multiple columns with the same name like "SELECT 1 AS col, 2 AS col;". More info at Relational_model#SQL_and_the_relational_model. 22.214.171.124 (talk) 21:38, 11 December 2008 (UTC)
From the article:
"SQL:2003 does not have a specific syntax to express equi-joins, but some database engines provide a shorthand syntax: for example, MySQL and PostgreSQL support
USING(DepartmentID) in addition to the
ON ... syntax."
This is not true. ISO/IEC 9075-2:2003 (E) defines the using syntax in 7.7, Joined tables:
<join specification> ::= <join condition> | <named columns join> <join condition> ::= ON <search condition> <named columns join> ::= USING <left paren> <join column list> <right paren>
Implicit outer joins
Full outer joins by left joins
I believe the example of how to construct a full outer join using only left joins is incorrect (the first one using outer left and outer right joins seems good). There is nothing ensuring that the two tables that are being unioned haved the same column ordering. The correct fix would be to ensure that the second left join has the same column ordering as the first left join by instead of doing doing
UNION SELECT * FROM department
UNION SELECT employee.*, department.* FROM department
You probably need a similar fix for the case of only using right outer joins. I verified that the command as shown does not work as stated in SQLite (version 3.4). Note that I am not a SQL expert though.
Foreign key error
The Sample tables section mentions the use of a foreign key:
This is incorrect given the definition of a foreign key , as it mentions: "The values in one row of the referencing columns must occur in a single row in the referenced table. Thus, a row in the referencing table cannot contain values that don't exist in the referenced table (except potentially NULL)."
Unfortunately, this seems to be the case, as the article itself says: "On the other hand, the employee 'Jasper' has no link to any currently valid Department in the Department Table." and as such this would violate the referential integrity constraint.
The examples are excellent, but I think it shouldn't be mentioned that it is a foreign key. I don't think it matters to the example anyway, because the presence of a foreign key is not required.
- Yeah. Department.departmentID is not a real Foreign Key, so the article should be changed. Aaron Schulz 14:00, 19 May 2008 (UTC)
Computation of Cartesian product
From the article:
"The SQL-engine computes the Cartesian product of all records in the tables. That is, processing combines each record in table A with every record in table B. Only those records in the joined table that satisfy the join predicate remain."
I seriously doubt the SQL engine will explicitly compute the Cartesian product for such a query, especially in the presence of a clustered primary key on Department.DepartmentID further optimized by a sort order on Employee.DepartmentID (as the example suggests). The result can be thought of as a Cartesian product with the unnecessary tuples removed, but the engine will benefit from using the index. —Preceding unsigned comment added by Svenmathijssen (talk • contribs) 10:21, 19 May 2008 (UTC)
- Yeah, it really would use the index and scan while joining with each row, otherwise it would be hella slow. Aaron Schulz 13:56, 19 May 2008 (UTC)
Full outer join emulations
All emulations provided should be corrected to use UNION ALL instead of UNION as it is now. The reason:
1) queries work in these special cases because returned rows are unique both for left joins and right joins. However in case of duplicate rows these emulations would give incorrect result.
2) queries with UNION (rather than UNION ALL) need more database resources because database must filter out duplicates.
Example from the data as provided in article:
SELECT DepartmentName from employee FULL OUTER JOIN Department ON employee.DepartmentID = department.DepartmentID; DEPARTMENTNAME --------------- Sales Engineering Engineering Clerical Clerical Marketing Marketing 8 rows selected.
Union gives us only unique rows:
SELECT DepartmentName from employee LEFT OUTER JOIN Department ON employee.DepartmentID = department.DepartmentID UNION SELECT DepartmentName from employee RIGHT OUTER JOIN Department ON employee.DepartmentID = department.DepartmentID WHERE employee.DepartmentID IS NULL; DEPARTMENTNAME --------------- Clerical Engineering Marketing Sales 5 rows selected.
Union all gives us correct result:
SELECT DepartmentName from employee LEFT OUTER JOIN Department ON employee.DepartmentID = department.DepartmentID UNION ALL SELECT DepartmentName from employee RIGHT OUTER JOIN Department ON employee.DepartmentID = department.DepartmentID WHERE employee.DepartmentID IS NULL; DEPARTMENTNAME --------------- Sales Engineering Engineering Clerical Clerical Marketing Marketing 8 rows selected.
About natural joins
User Mckaysalisbury under history page said: "natural joins are superior. Relational algebra doesn't even have a "join on", if you really think natural is prone to errors, that means you're using it wrong. Maybe we should axe the entire section?"
I completely disagree with this statement as well as I think it should be kept there. Writing SQL statements is not the same as dealing with Relational algebra - even more - many people writing SQL statements have never thought of Relational algebra. OK probably that's bad, but that's real life :) Also Natural joins ARE really evil with many possible side effects as I've explained it in my blog post and should be used with big caution. Also one of the SQL standard SQL-89 and SQL-92 authors Joe Celko said "Frankly, NATURAL JOIN was a bad idea. Any change to a table can suddenly add or remove a column in the join on the fly. You do not know what you have done until you see both table declarations. Much better to have explicit column names."
Please, if you are going to add a section on a type of join, please show the SQL code. This is, after all, a page on SQL joins, not the concept of "join" in general (if such a thing exists). Without any sample code, I have no clue how to implement this. Thank you. — Preceding unsigned comment added by 126.96.36.199 (talk) 21:59, 5 November 2015 (UTC)
I skimmed through and found no maths.
Sentence doesn't make sense?
This sentence under "Natural Joins" doesn't make sense to me. I'm not sure what the intended meaning is, it seems like two sentences have run together (see emphasis):
An error-message such as "ORA-25155: column used in NATURAL join cannot have qualifier" is an error to help prevent or reduce the problems that could occur may encourage checking and precise specification of the columns named in the query, and can also help in providing compile time checking (instead of errors in query).
I Disagree with Reviewer's View that the Content Should Be Simplified
This article is very good. There is no end to the abundance of dummied-down, impractically simplified introductions to SQL on the net. And as far as I can tell this is exactly mid-level as far as SQL is concerned. The top of this page implies this is what it is aiming for. If you want advanced, follow the path of the abstract math that underlies the language. Nothing about this is advanced. If you work in SQL you run across other's SQL queries that are loaded with these kinds of joins. As an example, I am writing this addition because I was spinning my wheels on the FULL OUTER JOIN construct on no less than three SQL interpreters.
It is hard to find a reference that presents joins as comprehensively and concisely as this article. If you search the net for SQL tutorials, you will find few this clear and concise on this topic. I think it would be a real shame to dummy this article down (simplify).
Additional Concern on Natural Joins from the Object Oriented Perspective
Natural join usage encourages naming conventions that run counter to the clean implementation of structured object oriented relational code wrappers.
If you are working in a relational system with an object-oriented wrapper to your relational objects, natural join naming conventions hinder solid polymorphic design. From an object perspective, you don't want primary key id fields named something different on each object. You want all of your objects responding to the same message (having the same method name), e.g. .id. This way if you have a heterogeneous collection of arbitrary objects, you know that you can send any of them the .id message and get it's primary integer key back. In other words, it doesn't matter what table the record is from, you always know .id will return the primary key. An example of just one of the many benefits of this approach is that if you combine this with a single sequence generator (generating unique key field values) for all of your id fields on all your relational tables, then it becomes easy to reference any arbitrary relational object by its id value alone, without reference to its table name even (building an application to achieve this is trivial). In other words, it is as if each object had its own UPC code. How ineffective would it be to reuse UPCs for each class of object in a grocery or department store? It should be clear to most people that this principle transfers naturally to software objects, at least where they map to real world objects.
From this perspective it is also redundant, for example, to have a department record with a field that calls it department_id or the like. With all deference to the survivors of the Monty Python troop, this is an example of "the department of redundancy department."
The OO approach:
The Monty Python approach:
The later naming convention is encouraged by the desire to employ natural joins.
In a data model supporting an OO wrapper, the convention of naming foreign key fields for the table that they reference is powerful. In this convention table names are *always* singular. This allows a foreign key field to simply be named for the table it references. The field name itself is singular or plural depending on the nature of the relationship between the tables, i.e. does it reference one, or many related objects.
With this paradigm, relational code wrapper generators can easily be written that read the database schema dynamically and generate object wrappers for relational records, tables, and result sets. If one has followed the conventions described above, the object code becomes immensely readable, and easy to write in an object oriented fashion. With such a consistent naming convention, the code wrappers written to implement joins (and other relational features) can be written on one superclass from which classes for each specific table can inherit. Adherence to such naming conventions allows, for example, for hiding the structure of intermediate tables used in many-to-many relationships. The underlying SQL necessary to support these structures can be be encapsulated in the superclass, which leverages the consistent naming conventions to achieve this.
I could gone on and on, actually. The power of this abstracted, polymorphic, and encapsulated approach is immense. It leads to a situation where the underlying relational structure melds seamlessly into the encapsulating code. This approach lends itself well to applications mapping software objects to the real world, and makes it easy for even novice developers to knock out some powerful applications without worrying about the mundane details of the structure of their queries. Many common queries can be auto generated dynamically in the superclass in this paradigm. More complex queries can be dealt with using naturalistic construction of "predicate" objects insulated from the nuances of SQL. This facilitates thinking problems through from the perspective of the business case being solved and not the underlying SQL. At the same time, all the power of this underlying SQL is fully leveraged.
Natural join field naming requirements are highly counter to this paradigm. They simply make a mess of it.
There are certainly situations where the above-outlined approach may be more of a hindrance than a help. There are no absolute rules in software development. But in applications that map real world objects to software objects, it is an extremely powerful approach. These kinds of systems are extremely common in our modern day world.
SQL developers may quickly zero in on the downside that there are a lot of duplicate field names across tables which makes ad hoc SQL queries using "select * from tab1, tab2" prone to confusion. However, in a properly structured system, these queries are not required as often as it may seem that they might be. And for ad hoc queries, many SQL user interfaces automatically disambiguate duplicate column names on the fly without user intervention. This is a common problem in SQL without consideration of the OO wrapper structure.
So how might someone make this point in this article in a succinct manner. Here is a shot:
- "The use of Natural Joins in SQL encourages field naming conventions which present complications for object oriented wrappers. There is a fundamentally inherent asymmetry between primary fields and foreign key fields which suggests that they should not be named the same. As an example, from an object-oriented standpoint, all objects should respond polymorphically to an ".id" message by returning their primary key. Foreign key fields should be named for the table they address. This is counter to the implied requirement by Natural Joins that a primary key field and a foreign key field be named the same."
I enjoyed your article, Treker, very informative. I disagree with your conclusion, however, as the wiki article is not about the OO paradigm or even about keys. Instead, i suggest something like this:
- "Note the use of either JOIN--USING or NATURAL JOIN in SQL requires the field naming convention used above. An alternative naming convention, such as used in these table creations,
CREATE TABLE department ( ID INT, Name VARCHAR(20) ); CREATE TABLE employee ( LastName VARCHAR(20), Department INT );
and which is perhaps just as popular, wouldn't work with JOIN--USING or NATURAL JOIN queries. It would require the ON form of query:
SELECT * FROM employee JOIN department ON employee.Department = department.ID;
Making content accessible to a wider audience is not tantamount to "dumbing down."
I can't tell whom that comment was for --possibly because what was being commented on was removed. But why see it as a zero-sum game? The art of writing is making the article accessible to a wider audience without making it less accessible to others. A few of the Wall Street Journal's Economics editors are masters of this: In a detailed article about the economy they will insert a concise elementary sentence --such as one would see in a primer-- clarifying what the "Fed" is, or what the inter-bank rate is, etc. This opens the article to a MUCH wider audience, yet it never registers with expert readers, who just fly over it without even noticing. It's not a distraction for experts.
Regarding: "Nothing about this is advanced. If you work in SQL..." Why write this article only for those who work with SQL? Such people have books on the subject, often acquired in school or other training. What do they need a Wiki article for?
Note that one of the reviewers (above) is a patent attorney. Who am I to say that a dairy farmer would not find this topic useful or enlightening? He somehow might even come up with a cure for cancer after reading this and some other articles? :^) Who knows?
Are the insert examples really necessary?
I think the sql examples are mostly useful, but I wonder if the section demonstrating inserting data is really necessary. The article already gives visual tables of the data to be used in the examples. I'm not certian how showing how to insert this data really adds anything. The article is about joins after all, not data insertion. Removing them would make the article flow better I think.
- Feel free to skip that section to preserve your flow. Cutting and pasting the code saves time and errors in constructing the sample tables. —Preceding unsigned comment added by 188.8.131.52 (talk) 04:33, 4 January 2011 (UTC)
First mention of join
I have changed the type in the first mention of "join", as required by MOS:LEAD. (Also, as a reader, I found the Courier type confusing.) In my opinion, the article is mostly about the concept of a "join", not the syntax of a particular language. (I believe that joins are used in other languages than SQL.) It might be better to move the article to something like "Database join" and leave "Join (SQL)" as a redirect. If you do, remember the disamb page. --RoyGoldsmith (talk) 16:20, 24 January 2011 (UTC)
It would be nice if there were an explanation for the typical motivation for using joins as opposed to a single table. I'm a newbie with respect to database design, so this was the (missing) information I was seeking when looking up the article.
Right outer join
The current text for right outer join states that they're rarely used because they can be replaced by left outer joins, but it doesn't provide any examples of why they might ever be used.
One situation I have occasionally found use for them is when I have a single table needing to be left outer joined to two inner joined tables. In this situation (assuming that the joins are all simple ID matches) you cannot simply left join table1 to table2 and then join table2 to table3, as any results for table1 which had no matches in table2 will be removed when the join from table1+table2 to table3 fails - the most common way of resolving this that I've seen is to left join table3 to table2, which works in the sense that table1+table2 results with null information for table2 will also receive null information for table3, but it leaves open the possibility of null results being attached for table3 to table1+table2 results which do have a table2 component.
In my mind it is a superior solution to first join table2 to table3, and then to right outer join the table2+table3 combination to table1. Another option is to join table2 to table3 in a subquery and then left join the results of that subquery to table1, but this makes the query more complicated than necessary. --184.108.40.206 (talk) 05:05, 24 March 2011 (UTC)
Self join example
I think the example given in the Self Join section -- finding pairings of employees in the same country -- is too unreal to be helpful, and request that it be replaced with the fairly standard parent-child example of listing all employees along with the name of their manager. Matthew C. Clarke 07:33, 20 May 2011 (UTC)
Joining more than two tables - Comments on Inner Joins
I wonder if this article should have a section about joining three or more tables. I seem to remember that there's a faster way to do this that doesn't come from a Cartesian product of the three tables, but from the (smaller) Cartesian products of two of the tables, the results of which are processed in another Cartesian product with the third table. This speeds things up. Does anybody know any more about this? —MiguelM (talk) 03:10, 7 July 2011 (UTC)
Most real-world queries involve more than two tables. Have never even imagined a Cartesian product of three tables produced in a single operation. Don't think that a three-way inner join exists except in theory. The execution cost could be enormous compared to other methods. Three tables inner joined would probably be processed in order, with the inner joined results from the first pair inner joined to the last table. The execution plans produced by database managers would bear this out (my experience is with MSSQL). The actual order of the inner joins may be subject to change by the database's optimizer based on statistics. If one of the inner joins is more selective (reduces the record set to a relatively small number) than the other, the optimizer may reverse the order to reduce cost. This would not be obvious unless you review the actual execution plan but the results should be the same.
I work every day creating complex SQL queries in a reporting database and don't even bother to count the number of tables joined together in a query. A dozen would be typical, 20-30 in a single view or stored procedure is not surprising. Tables range from a handful of rows to 3-billion, four fields per table to 120 or more, multi-gigabyte sizes for many tables.
When querying a reporting database I've never been concerned about cartesian products (except when making a mistake in the join fields). Using MSSQL and no doubt other databases, the optimizer takes care of the details.
This article is very misleading in that it encourages inner joins at the exclusion of others. Who says they are the most common or default? The wording says "for applications". I have never read that anywhere else and have spent many hours studying books written by leading experts.
My method for years is to typically use left outer joins (MSSQL) and inner joins rarely, only where it has been proven by tests that NULL values won't eliminate data/returned rows along with deleting related information from other tables. My database doesn't encforce referential integrity, and that design decision is not something I control. Right outer and Full outer joins are pretty rare but have come up. Use UNION of queries many many times.
Inner Joins are NOT always faster than Left outer joins. Any complex query has many other considerations than just slamming in inner joins everywhere. Have seen inner joins kill a server as it matched up two tables with tens of millions of records before filtering the data and returning a list of fields. Speed of processing isn't the only consideration.
IF YOU USE AN INNER JOIN AND DON'T REALIZE THAT A TABLE HAS SOME NULL VALUES ON THE JOIN KEYS THE DATABASE WILL SILENTLY DISCARD BOTH SIDES OF THE JOIN! NO ERROR MESSAGE. YOU WILL GET ENOUGH DATA TO THINK IT'S CORRECT BUT WILL BE WRONG IN A SMALL WAY EVERY TIME!! OR IF THERE ARE A LOT OF NULLS YOU WILL BE WRONG IN A BIG WAY!!!
When joining a large number of tables you need to know your data. Table record sizes, expected number of rows selected, whether indexes are available that cover all of the fields that you want returned so the database doesn't have to plow through the entire table. Then it can be structured using a variety of methods to 'get the number of records down to the smallest number as soon as possible". After that, everything is efficient or if it isn't it doesn't matter.
Nested queries, correlated subqueries, derived tables, common table expressions, functions, temp tables, custom indexed tables, multiple sequenced queries in a stored procedure are ways to structure complex queries. They all belong in your bag of tricks, along with the knowledge of where they are best used. Learn as you go, figure out how to use the tools to get cost figures and record time and cost results as you make changes. The query will get faster (or you will backtrack so always make multiple backups).
Everyone seems to want the faster code, maybe to support transaction processing which typically involves a small number of tables, limited number of fields, updating minimal number of rows in a controlled process. This isn't NASCAR. Speed is important but accuracy is more important (still efficiency IS important).
Natural Join section is unclear
I added a clarifying sentence to the section on Natural Joins, explaining why they're dangerous. Without it, it's not at all clear what the difference is between natural joins and equijoins, and it made me want to avoid both of them. —MiguelM (talk) 03:46, 7 July 2011 (UTC)
implicit "OUTER" for LEFT JOIN?
- Is LEFT OUTER JOIN the same as LEFT JOIN in standard SQL?
- Fulfill MySQL, PostgreSQL etc. this standard?
- Why do exist different symbols for "LEFT JOIN" (⋉) and "LEFT OUTER JOIN" (⟕)?
The OUTER keyword is optional. I.e. LEFT JOIN means LEFT OUTER JOIN, and RIGHT JOIN means RIGHT OUTER JOIN. (In both cases there are an "outer" table.) — Preceding unsigned comment added by 220.127.116.11 (talk) 09:17, 19 October 2011 (UTC)
It was "CROSS JOIN is not the Cartesian Product in MYSQL" but I had an "ON" condition. Also Cartesian Product: SELECT * FROM TableA, TableB sorry, firstname.lastname@example.org
I found this article to be confusing
Please add a section about "LATERAL JOIN"
See https://wiki.postgresql.org/wiki/What%27s_new_in_PostgreSQL_9.3#LATERAL_JOIN — Preceding unsigned comment added by 18.104.22.168 (talk) 11:31, 30 May 2015 (UTC)
Natural join is described in two places now
Natural join does not have an SQL example
It would be great to give an SQL example for a natural join, because I was trying to distinguish between a natural join and an inner join, it seems like inner join is a superset of natural join, is it perhaps less efficient? All the other types of joins have exmaples; please add an SQL example for natural join. SystemBuilder (talk) 18:06, 5 May 2016 (UTC)