Cool. I appreciate the help. Thanks again


--
Posted via http://dbforums.com

Jan, it appears something must be missing in our algorithm. I had no
problem implementing it and I put a print statement in place of the
check of the join condition. That way I can see that I'm walking the
nodes correctly.



... that seems true for the algorithm but not for SQL FROM clauses I'm
trying to model. The join conditions can be Inner, Outer, Left, or
Right. For example, in my 3 table query above join conditions like these
denote a valid query:



A Left Join C

C Inner Join B

A Left Join B



In my code I load the 3 tables and 6 edges (3 edges in both directions)
and I walk the graph with this output:



(TableA,TableC) Left Outer Join

*** (TableC,TableB) Inner Join

(TableA,TableB) Left Outer Join



At the asterisks the code would have stopped to report a conflict. Am I
doing somethng wrong or do we need somethin more complex to handle the 4
possible states of a join? Any ideas?


--
Posted via http://dbforums.com

bill_dev wrote:

What you call an outer join is what I call a full outer join or a join
that is both full on both sides. What you call a left join is what I
call a left outer join or a join that is only full on the left side, et
cetera. Since outer joins are not really part of the relational model
the terminology tends to vary a little.

I would have used 1 undirected edge per join condition, but this will
also work.

What is the problem? The join between B and C should indeed be a (full)
outer join as is reported by the algorithm if you don't let it stop at
the first conflict it sees. This is because it will report that the join
should be full on the side of B and full on the side of C, so therefore
a full outer join.

-- Jan Hidders