Re: Navigation question

On Feb 27, 6:22 am, Kenneth Downs <knode.wants.t..._at_see.sigblock> wrote:
> dawn wrote:
>
> > Do large, production-quality, highly usable and useful, data-based,
> > read-and-write software applications actually exist where there is no
> > code in the software that navigates around the database?
>
> I would rephrase the context as this perhaps, "Is there an ideal user
> interface for presenting relational data?"

Well, that might be your question, but I don't particularly care if it is "relational data" or data that could have been modeled as relational data, but has not been. So, perhaps we could say "database data" or "persisted data" or "stored data" instead? On top of that, my preference is that there be many options as what is ideal for one situation might not be ideal for another. So, I'm interested in what it is that has given "database navigation" (as a design pattern) a bad name.

> And from there ask the
> question, "How do you implement that interface, what elements are required
> on server and in code?"
>
> It seems to be taken as a given that foreign key is the basis of all user
> "navigation", the travelling from one context ( a row or rows of a table )
> to another context. By this I mean this has been the basis of every app
> I've seen whether they knew it and said it or not.

Yup.

> Finally, to your actual question, I've never seen one. All user
> applications "navigate" as the user desires, from one context to another,
> otherwise you don't have a usable system (if I understand your question).
> As I mentioned, I believe the foreign key is the foundation of these
> features.

After some discussion, I removed "user navigation" or any database navigation where there are user events driving it. Some suggested that is user navigation, but not database navigation. I can see it is a different pattern than having the code/DBMS combo navigate without user events, so I narrowed down the question so that it includes "logical navigation" of the database between the code & DBMS with no user events cutting into this navigating process. Applications still often or even typically navigate around the database, but it is far from cool to suggest that. I like set processing and set-based queries when looking for large result sets, but when working with a single "entity" navigating around is pleasant and might even been a good thing to do at times. The anti-navigation mantra that seems to have come to us by way of "relational theory" seems very difficult to pin down. Just what is this bad navigation and why is it bad? I'm still not understanding. Thanks. --dawn

> --
> Kenneth Downs
> Secure Data Software, Inc.
> (Ken)nneth_at_(Sec)ure(Dat)a(.com)
Received on Tue Feb 27 2007 - 21:54:59 CET