Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
elwoos
Master Smack Fu Yak Hacker
2052 Posts |
 Posted - 2011-01-13 : 06:58:40
|
| One of our systems uses a "Relational Database Management System" which I have just discovered does not allow any type of outer join. Can it therefore be reasonably called relational? As a result of this discovery there has been some discussion here as to when outer joins first came into general use, anyone have any ideas?thankssteve-----------I used to think I wasn't a morning person but it never got better in the afternoon |
|
|
Ifor
Aged Yak Warrior
700 Posts |
Posted - 2011-01-13 : 08:05:33
|
| As an OUTER JOIN can be obtained by the UNION ALL of an INNER JOIN and a NOT EXISTS, if the system supports UNION I cannot see why it would be any less relational than other SQL based system.I do not know when outer joins first came into general use. |
 |
|
|
Michael Valentine Jones
Yak DBA Kernel (pronounced Colonel)
7020 Posts |
Posted - 2011-01-13 : 10:21:46
|
| Here is an abstract of a paper from 1993 that says that it was already part of the proposed SQL2 standard and that is was already being introduced in major relational DBMSs.http://www.almaden.ibm.com/u/mohan/aries_papers.html"[PiMC93] Pirahesh, H., Mohan, C., Cheng, J. Sequential and Parallel Algorithms for Unified Execution of Outer Join and Subqueries, IBM Research Report, IBM Almaden Research Center, June 1993. The outer join operation is being introduced in major relational DBMSs, and is already proposed as part of the emerging SQL2 standard. The outer join operation plays an important role in the handling of complex object queries, path expressions in object-oriented query languages, and universal and existential subqueries in relational languages. Thus, outer join is an important primitive. Similar to regular joins, good performance of outer join is critical in query processing. In this paper, we introduce a unified algorithm for handling of outer join and subqueries. We first introduce a general execution algorithm for an outer join of any complexity, as required by the SQL2 standard, where the outer join predicate can be a full WHERE clause of SQL, including conjuncts, disjuncts, subqueries, etc. Typically, outer join queries are much simpler, e.g., involving equijoins. For this category of queries we introduce, in considerable detail, a much more efficient algorithm, called the specialized algorithm. One important property of these algorithms is that they allow several existing efficient join algorithms to be extended to support outer join. We also present methods for parallelizing the execution of an outer join. We then refine these methods for handling SQL subqueries."CODO ERGO SUM |
|
|
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2011-01-13 : 11:22:31
|
quote:
Can it therefore be reasonably called relational?
If you ask Chris Date, any system that allows nulls is not relational either. He has a bunch of objections to things SQL does that don't match relational theory. (If you catch me on a bad day, I'd even argue that the only correct join is a NATURAL one)  I know Visual Foxpro supports SQL statements (including outer joins), but the underlying dBase/FoxBase/FoxPro API would never be considered relational according to Codd et al. (or me for that matter, having programmed dBase) Being "relational" is more than language syntax or support for certain features. |
|
|
|
X002548
Not Just a Number
15586 Posts |
|
|
|
|
|
|
|
technical pedantry