Re: By The Dawn's Normal Light

From: erk <eric.kaun_at_pnc.com>
Date: 27 Oct 2004 13:29:58 -0700
Message-ID: <1098908998.734487.300670_at_c13g2000cwb.googlegroups.com>


> and relations that are functions (have a primary key) seem to be even
more
> useful to me, but I have just as much proof of that as there is that
> relations are a good top level structure.

They're useful all right - just not sufficient. Clearly the editing-screen case is one where the user might know the order number (for example), and that's a useful key. But those search screens if they don't know what they're looking for... oy.

> We want to minimize the complexity for the user even if it means the
tools
> need to be more complex.

Sure, but that's what applications are all about - users shouldn't have to know about things like relations and normalization. Nonetheless, when you get "power users' that know just enough about SQL and reporting tools to be dangerous, you end up needing to educate them on normalization as well, unless you write functions that cover some of the joins.

I find that when you commit to lists as a data management structure (I've done it in the past), you lock yourself in. And maybe it's just my experience, but that lock-in has always come back to bite me, requiring lots of logic just to do what a simple series of joins would accomplish.

XPath and XQuery automate some of that, but I still think the structures are nonsensical. A look at IDs and IDREFs, and their custom alternatives, suggests that the hierarchy is limited.

> I'd say that for any DBMS, there should be a minimal number of
> "primary" structures -

> by def of "primary" - I agree. I'm not sure that the primary vs
everything
> else approach with structures is that useful. I agree there are lots
of
> issues with Java, as with any language I've ever used, but I prefer
having
> Object as the most abstract structure and then we can define any type
of
> collection we need.

Sure, but how many do you need? In Java I've had little need for more than Set and Map primarily... and often in using those two I've ended up wishing I had a relation. I was writing loops inside query-type methods that went through one or more collections, gathering up values from objects that met various criteria, and often returning a new object that represented basically one tuple of a relation... when a simple join would have made all that a 1-liner. Visitor and similar patterns can help, but the awkwardness remains.

> We need not be married to the relation.

I agree that we need not... but it's useful.

> There is then difficulty in querying the data at this point, but we
can address
> that too.

Sure we can address it, but I'd say that the relation is the result of someone doing just that - addressing the deficiencies of hierarchical data stuctures.

> I'd suggest Haskell instead, but there is no reason to believe it
will have
> any of the impact that Java has had (and many reasons to believe it
will
> not).

Yes, and I think the dearth of real computer science education is one. I consider my discrete math and circuit design classes to be some of my better, more abstract ones. But rather than taking those ideas and really using them, today those tend to be regarded as nuisances to be completed and forgotten. I have to agree with Fabian Pascal: universities are becoming trade schools, and worse yet, extended product seminars.

Without sound education in logic and math, languages like ML and Haskell have no hope. That type theory and logic can be a bear, though it pays dividends.

> > simplify as much as possible without oversimplifying.
>
> This is one of those statements that I think got the relational
theorists in
> trouble. We don't really want to simplify the mathematics of
language in
> order to make language more useful. In fact, if we have a language
that is
> very useful, the mathematics of it is likely very complex. We want
it to be
> simple for the user to do what they need to do, not for the database
engine.

I agree, and optimizing relational operations is complex. Perhaps the problem is that I don't think of relations as complex to use, nor do I think of them as "competing" with lists. A list is a data structure, and while relations are as well, taken together with relational operators and integrity constraints, they form a declarative language for data, which takes work away from the programmer.

The end user will see the same type of application, but the goal (in my mind) is to get the programmer to declare what sorts of screens and reports and logic they want, without having to replicate logic from the DB to the GUI and to write lots of code traversing in-memory data structures.

> > At the same time, user extensibility is critical.
> > Consistent and well-defined, high-level operators are powerful -
> > high-level because they operate over all relvars you can define.
> > Balancing all of those things, I think the relation alone delivers
> > maximum value for minimum pain.
>
> Well, then, qed ;-)

Heh. I knew you'd see the light (that my endless repetition is annoying).

  • erk
Received on Wed Oct 27 2004 - 22:29:58 CEST

Original text of this message