At 08:04 PM 31-01-01 +1300, you wrote:

>Jason Wharton wrote:
>
> > No, I don't know what you mean by cascade.
>
>Let's say I have four fields to sort by clicking on the respective
>title.
>A click on the first field sorts down and to the right. Same for the
>other fields.
>If there is no field to the right then the sort goes only downward.
>
>Now, select a field in the middle (two or three) theoretically I could
>sort down to the right and to the left?
>The more I think about it, it does not seem to make much sense.

No, it doesn't. "Cascading" is a concept describing a rightward & downward
hierarchy which is unambiguous. You cannot turn that logic upside down and
establish an unambiguous upward or backward path without redefining the
relationships. It's something we *can* do for certain requirements and
with certain data structures, by using alternative join statements in
*different* queries. Those structures are many:many and some (recursive,
not well-recommended) self-referencing relationships.

In Client/Server, with queries as your tool, you can do a surprising amount
of "logic-defying stuff" from a drill-down approach that picks up
parameters from a selected row in one dataset and passes them to a
different one. You have much more server-friendly ways to display data
from fresh angles, that's unachievable by restricting yourself to
hierarchical key structures. (By "restricting" I mean forcing the
unnecessary inclusion of ever-increasing key stacks as you drill down your
dependency model.) Apart from being quite unnecessary in a RDBMS that
supports any join, it's also likely to bang you into the absolute key size
limit at some point, especially if you are using a multi-byte character set.

Helen

All for Open and Open for All
InterBase Developer Initiative · http://www.interbase2000.org
_______________________________________________________