Should I avoid loops in joins? - sql

Question

I remember I was taught to never create a loop when joining tables in sql.
In effect, using Business Objects it even tells me if there are loops in the schema I've defined in the Universe.
I've tried to search on the web about this statement but I wasn't able to find a reference.
Why is it dangerous to do this?
Edit: maybe I was too succint.
My question wasn't about looping intended as a "FOR LOOP" or similar.
I was talking about something like this WHERE clause in a SELECT statement:
WHERE TABLE1.foo = TABLE2.foo
AND TABLE2.bar = TABLE3.bar
AND TABLE3.baz = TABLE1.baz
if you draw the relation you will see "a loop" in the join.
Is this dangerous from a correctness and/or performance point of view?
Thanks to all.
Edit 2: added an example.
I've just thought an example, maybe it isn't the best, but I think it will serve to understand.
------------ ----------------- ----------------------
- DELIVERY - - DELIVERY_DATE - - DELIVERY_DETAILS -
------------ ----------------- ----------------------
- id - <--- - id - <----- date_id -
- company - |----- delivery_id - - product -
- year - - date - - quantity -
- number - ----------------- - datetime_of_event -
- customer - ----------------------
- ----------
1 <-----> N 1 <----> N
In the DELIVERY table every delivery appears only once
In the DELIVERY_TABLE we have the list of every date in which the delivery was processed. So, a delivery may be prepared in several days.
In the last table we have the details of every delivery. So, in this table we track every event related to the preparation of the delivery
So, the cardinalities are 1:N for each couple of tables.
The join is very simple:
DELIVERY.id = DELIVERY_DATE.delivery_id AND
DELIVERY_DATE.id = DELIVERY_DETAILS.date_id
Now, suppose I want to join another table, where I have some other information for a delivery in a certain date.
Let's define it:
------------
- EMPLOYEE -
------------
- company -
- year -
- number -
- date -
- employee -
------------
Now the join should be:
DELIVERY.id = DELIVERY_DATE.delivery_id AND
EMPLOYEE.company = DELIVERY.company AND
EMPLOYEE.year = DELIVERY.year AND
EMPLOYEE.number = DELIVERY.number AND
EMPLOYEE.date = DELIVERY_DATE.date
To sum up, I'll end having EMPLOYEE joining both DELIVERY and DELIVERY_DATE, having the cycle in the join.
Should I rewrite it in this way?
EMPLOYEE.company = DELIVERY.company AND
EMPLOYEE.year = DELIVERY.year AND
EMPLOYEE.number = DELIVERY.number AND
EMPLOYEE.date IN (SELECT date FROM DELIVERY_DATE d WHERE d.delivery_id = DELIVERY.id)
Edit 3: finally found a link
As usual, when you've given up searching for a link, you find it.
So, this article explains all. It's related to Business Objects, but the content is generic.
Thanks to all for your time.

Answer 1

EDIT: I see from the update that this is an issue that's specific to a BO designer, where a table is used more than once, but BO automatically combines join clauses, which then incorrectly (or, rather, unintentionally) restricts the result set. This question actually has nothing to do with cycles, per se, it's really about using entities in more than one context in the same query. I'll leave my original answer below, even though it doesn't really address OP's concern.
Disclaimer: This is a non-answer answer, because it's both an answer and a question. It probably should be a comment, but you can't comment unless you ask/answer questions, but since I genuinely want to help, I'll do it the only way I can, even if it's not the way things are done here. So sue me.
The short answer is no, you shouldn't avoid loops (or "cycles") in joins.
More to the point, queries are constructed so as to declare the correct logical condition(s) to produce the data you're looking for. The same logical condition can often be established in many different ways, so sometimes it makes sense to ask if one way is preferable to another. This becomes of particular interest when performance is important. But first and foremost a query must return the right result set. How this is accomplished depends on the underlying schema. And this is what you really should be focused on.
In your example, why role does EMPLOYEE play regarding the DELIVERY tables? Why would you join on those columns? What would that mean that an EMPLOYEE has the same "date" as a delivery? I understand it's a contrived example, but the point I'm trying to make is that whether joins create a cycle in the graph or not is wholly (well, principally) dependent on what a particular result set's logical meaning is.
And on the issue of JOIN syntax, using JOIN...ON clauses is preferable to WHERE clauses because it separates what you need to do to combine entities from data filtering operations.

Answer 2

Well, your question is easy. You should not be using where clauses to perform joins. You should be using on clauses. Your joins can be expressed as:
from Table1 join
Table2
on Table1.foo = Table2.foo join
Table3
on Table2.bar = Table3.bar and
Table1.baz = Table3.baz
Whether this is appropriate or not depends on your data structures. Sometimes it is. You shouldn't worry about it.
By the way, I wouldn't refer to this as "loops" which is very associated with "for loops" in programming and nested loop joins in SQL. You might refer to this as cycles in join conditions.
Wmax . . . as for the new join syntax. It is not "just" a matter of taste. The "," in a from clause means "cross join". This is a very expensive operation, in most cases. It is much better to be clear about what you want to accomplish:
FROM A cross join B
is much clearer about its intentions than:
FROM A, B
Second, if you leave the "," out, you still have valid syntax:
FROM A B
However, this means something very different (assigning the alias B to the table A).
The third reason is the most important reason. The old syntax does not have a way of expressing left outer join, right outer join, and full outer join.
So, to write clearer queries, to avoid errors, and to access better functionality, you should learn the new syntax.