Talk:Join (SQL)

message: 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)
replies: text: 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)
thread_title:  SemiJoins 

message: 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)
replies: text: 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)

text: Surely these Venn diagrams are incorrect. The sets are disjoint and so there can be no intersection. For example when A is the set of employees and B is the set of Departments then the set of elements x where x is a member of A and x is also a member of B is {}. If A is the set of rows in table A and B is the set of rows from table B then the intersection of A with B is the {} since no row appears in both tables. Joins create tuples that is a concatenation of an A row with a B row. It would then be appropriate to consider the set of tuples. In the diagrams shown, A_tuple would be the set of A-B tuples where the rows from A which have a matching row in B as well as A rows which have no B match being substituted with null. B_tuple would be the set of complementary rows based on rows from B. The intersection of A_tuple and B_tuple would be joined rows with matching non-null values from both A and B. STACS-BM (talk) 22:10, 9 February 2024 (UTC)
thread_title: Images for join types

message: 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 63.234.230.254 (talk) 16:04, 11 August 2014 (UTC)
thread_title:  Left Outer Join 

message: 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...
Won't edit, as I don't think implementation docs are necessarily a good source for the standard, and I may be misunderstanding.
DocAvid (talk) 21:03, 10 January 2008 (UTC)
replies: text: 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)
thread_title:  Equi-Join Columns 

message: 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>
This section should not have another example than the one used throughout the article. It is confusing to see a natural join demonstrated twice with two similar but different datasets.  — Preceding unsigned comment added by 68.132.255.43 (talk) 15:39, 5 June 2017 (UTC)
thread_title:  Equi Joins

message: Does this article mean that SQL 2003 doesn't support implicit left/right joins using *= and =* syntax? 71.4.124.241 (talk) 18:10, 14 April 2008 (UTC)
replies: text: ANSI/ISO SQL has never had that implicit outer join syntax. 155.4.126.237 (talk) 07:47, 24 May 2017 (UTC)
thread_title:  Implicit outer joins 

message: The Sample tables section mentions the use of a foreign key:
"In the following tables, department.DepartmentID is the primary key, while employee.DepartmentID is a foreign key."
This is incorrect given the definition of a foreign key [1], 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.
[1] http://en.wikipedia.org/wiki/Foreign_key  —Preceding unsigned comment added by Svenmathijssen (talk • contribs) 10:04, 19 May 2008 (UTC)
replies: text: Yeah. Department.departmentID is not a real Foreign Key, so the article should be changed. Aaron Schulz 14:00, 19 May 2008 (UTC)
replies: text: Foreign keys makes no difference when joining. You declare foreign keys to ensure data consistency (when INSERT/UPDATE/DELETE.) No need to confuse less experienced users here, talking about foreign keys. 155.4.126.237 (talk) 07:48, 24 May 2017 (UTC)
thread_title:  Foreign key error 

message: 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)
replies: text: 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)
thread_title:  Computation of Cartesian product 

message: 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.
Gintsp (talk) 16:39, 28 July 2008 (UTC)
thread_title:  Full outer join emulations 

message: 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."
Gintsp (talk) 13:08, 15 September 2008 (UTC)
thread_title:  About natural joins 

message: I skimmed through and found no maths. 
Why didn't anyone explain the joins from the correct
relational point of view, which is formal/mathematical?  —Preceding unsigned comment added by 193.136.19.11 (talk) 09:55, 2 October 2008 (UTC)
thread_title:  MATHS? 

message: 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).
Xurizaemon (talk) 22:51, 12 March 2009 (UTC)
thread_title:  Sentence doesn't make sense? 

message: 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).
--Ttreker (talk) 11:29, 25 April 2010 (UTC)
thread_title:  I Disagree with Reviewer's View that the Content Should Be Simplified 

message: 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:
:department.id
The Monty Python approach:
:department.department_id
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."
--Ttreker (talk) 03:48, 26 April 2010 (UTC)
replies: text: "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;
"
Martin F  — Preceding unsigned comment added by 174.6.76.165 (talk) 20:10, 25 September 2013 (UTC)
thread_title:  Additional Concern on Natural Joins from the Object Oriented Perspective 

message: 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?
CousinJohn (talk) 20:04, 26 May 2010 (UTC)
thread_title:  Making content accessible to a wider audience is not tantamount to "dumbing down." 

message: 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 certain 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.
 MaxMahem (talk) 03:18, 19 November 2010 (UTC)
replies: text: 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 69.171.176.210 (talk) 04:33, 4 January 2011 (UTC)
thread_title:  Are the insert examples really necessary? 

message: 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)
thread_title:  First mention of join 

message: 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.
: → Database normalization. Jpatokal (talk) 02:34, 23 May 2011 (UTC)
thread_title:  Motivation 

message: 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. --210.11.199.87 (talk) 05:05, 24 March 2011 (UTC)
thread_title:  Right outer join 

message: 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)
thread_title:  Self join example 

message: 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)
thread_title:  Joining more than two tables - Comments on Inner Joins

message: 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)
thread_title:  Natural Join section is unclear 

message: * 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" (⟕)?
I am confused. :-( --RokerHRO (talk) 12:10, 13 July 2011 (UTC)
thread_title:  implicit "OUTER" for LEFT JOIN? 

message: Why are there two natural join sections?
Why does it not use the example introduced at the top consistently?  — Preceding unsigned comment added by 84.154.15.166 (talk) 19:14, 7 December 2014 (UTC)
thread_title:  I found this article to be confusing 

message: See https://wiki.postgresql.org/wiki/What%27s_new_in_PostgreSQL_9.3#LATERAL_JOIN  — Preceding unsigned comment added by 89.246.199.104 (talk) 11:31, 30 May 2015 (UTC)
thread_title:  Please add a section about "LATERAL JOIN" 

message: Both by itself, and inside Inner Join.  The two should be merged.  ★NealMcB★ (talk) 00:46, 23 December 2015 (UTC)
replies: text: NATURAL JOIN is just a special case, of either INNER JOIN or OUTER JOIN. Keep things together, i.e. no main section for NATURAL JOIN. Also JOIN USING syntax should be placed under INNER and OUTER JOIN. 155.4.126.237 (talk) 07:48, 24 May 2017 (UTC)
thread_title:  Natural join is described in two places now 

message: 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)
replies: text: A NATURAL JOIN can be either an INNER JOIN (select ... from t1 NATURAL JOIN t2), or an OUTER JOIN (select ... from t1 NATURAL LEFT JOIN t2). 155.4.126.237 (talk) 07:49, 24 May 2017 (UTC)
thread_title:  Natural join does not have an SQL example 

message: Hello fellow Wikipedians,
I have just modified one external link on Join (SQL). Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
*Added archive https://web.archive.org/web/20121216123745/http://www.coffingdw.com/sql/tdsqlutp/join_index.htm to http://www.coffingdw.com/sql/tdsqlutp/join_index.htm
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
Cheers.—InternetArchiveBot (Report bug) 12:40, 26 April 2017 (UTC)
thread_title:  External links modified 

message: In section Inner join, the statement, "The following example is equivalent to the previous one, but this time using implicit join notation:" is false because the two example queries are not equivalent and do not produce the same result.  In order to make the two queries equivalent, the second query should read:
SELECT employee.LastName, employee.DepartmentID, department.DepartmentName 
FROM employee, department
WHERE employee.DepartmentID = department.DepartmentID;
and the query result should read:
Employee.LastName	Employee.DepartmentID	Department.DepartmentName
Robinson         	34                   	Clerical
Jones            	33                   	Engineering
Smith            	34                   	Clerical
Heisenberg       	33                   	Engineering
Rafferty         	31                   	Sales
--RedViking20200702 (talk) 06:57, 11 August 2020 (UTC)
thread_title:  Example queries in section "Inner join" are not equivalent 

message: The section on join indices probably needs (in 2022) attention by someone knowledgeable in the matter. Specific issues:
# It places great emphasis on summarising the capabilities of specific products, and given that it cites the year 2012, there is a definite risk that this information is now outdated.
# It fails to explain how a join index is any different from an ordinary index. The way it describes these indices — that they are updated when the underlying tables change, that they cover a subset of the columns, etc. — sounds very much like the way an ordinary index works. I suspect that the key point is that a join index combines data from several tables, whereas ordinary indices would not, but the article should state the matter explicitly.
90.129.219.218 (talk) 10:32, 21 March 2022 (UTC)
thread_title:  Join index section 

message: An editor has identified a potential problem with the redirect :Join (SQL and has thus listed it for discussion. This discussion will occur at Wikipedia:Redirects for discussion/Log/2022 October 27#Join (SQL until a consensus is reached, and readers of this page are welcome to contribute to the discussion.  Steel1943 (talk) 19:41, 27 October 2022 (UTC)
thread_title:  "Join (SQL" listed at [[Wikipedia:Redirects for discussion|Redirects for discussion]]