Re: Argument for 1NF by counter-example

From: Tony Douglas <tonyisyourpal_at_netscape.net>
Date: 28 Oct 2004 14:20:44 -0700
Message-ID: <bcb8c360.0410281320.496ab93a_at_posting.google.com>


"Dawn M. Wolthuis" <dwolt_at_tincat-group.comREMOVE> wrote in message news:<clmepo$bmj$1_at_news.netins.net>...

A couple of posts seem to have disappeared from Google, so I'm kind of replying to the wrong message. Anyway...

> "Marshall Spight" <mspight_at_dnai.com> wrote in message
> news:DStfd.10431$R05.4156_at_attbi_s53...
> > "Tony Douglas" <tonyisyourpal_at_netscape.net> wrote in message
> news:bcb8c360.0410260632.64438b61_at_posting.google.com...
> > >
> > > I'd suggest that *because* of the efforts of the various SQL:2003
> > > standards committees, we'd best look elsewhere for the next level of
> > > database work. Some will drone on about Tutorial D, but I can't admit
> > > to being a fan. Personally, I'd like to see the next generation
> > > working from a declarative direction; either from Prolog or
> > > alternatively something like Haskell plus relations. Haskell +
> > > relations would have the distinct advantage of giving us a very
> > > flexible, working, proven and mathematically respectable type system
> > > too.
> >
> > I like the TutD algebra.
> >

Well, the algebra is pretty much independent of Tutorial D; with Haskell (say) extended to know about relations and the relation operators, you'd be pretty much in the same place re. the algebra.

> > I like Haskell's algebraic data types, parametric
> > polymorphism, and list comprehensions, but I'm not sure if one really
> > needs algebraic data types if one has relations, nor am I sure about
> > parametric polymorphism when one has relations, which are
> > polymorphic by nature. List comprehensions are awesomely
> > cool but provide nothing that a good relational language gives
> > you. (Although the haskell people clearly understand reduce
> > better than the relational people, the relational people have
> > a better handle on map and filter, which are just simple cases
> > of select/join.) Do we need union types? Dunno. I'm pretty
> > sure we need enumerated types.
> >

Hum. I think here I go back to the "types are orthogonal to relations" argument. I'm a little confused by your "relations are polymorphic by nature" comment. Could you expand on that ?

In one sense, relations are one thing the language expresses; they have an additional interesting property that they survive between program invocations / expression evaluations. Having relations shouldn't preclude doing anything else. Whether you *need* the other stuff, or whether you pretend to have it but use syntactic sugar for relation constructs, is an interesting, alternative question.

I also think that algebraic data types finesse an answer to the question of null and 3VL. Which is a very good thing.

> > Prolog seems like a good answer to the recursive queries problem.
> > You get a nice *general* solution for transitive closure, without
> > a special-purpose tclose or connect-by or whatever. You can
> > also do reflexive closure, and some other cool stuff.
> >

Well, Prolog is a start, but it would need several issues sorting before progressing, the main two being the ordering of functor arguments and the ordering of facts/clauses affecting the evaluation of a predicate. Types would be nice too ;)

> > Do we need subtyping polymorphism? Not clear; maybe
> > the generalize/specialize techniques of relational are enough.
> >
> > Do we need a better set of relational operators? You bet!
> >

Hm ! Could you expand on this ? I'm pretty sure what you mean isn't what I'm reading :)

> > Do we need some kind of nested relations? I'm pretty sure we do.
> >

Well, I get into discussions on this. Whether we *need* them or not, the definition of a relation permits them, so we *should* have them. Otherwise we can't claim to be properly implementing relations.

> > We also need a module system. What about some kind of dynamic
> > dispatch? The OO single-dispatch solution to this has an excellent
> > power-weight ratio, and also some kind of object mechanism
> > is a great solution to a number of different modularity concerns.
> > I'm still not clear how objects (specificially, non-constant fields)
> > interact with relations, though.
> >

I'm going to chuck something up in the air and see what happens.

I think the whole idea of putting an object in a database is absurd.

Firstly, the object oriented languages don't seem to agree on what *precisely* an object is; the views of say, Java, C++, Simula and Smalltalk seem to differ, albeit sometimes subtly, on this. If they can't agree on what an object is/means, how can we agree on what it means to store an object in a database ? Also, the objects have, for me, a very particular application - modeling dynamic interacting processes. What does it mean to store one of these things in a database ? If we're using them for, effectively, abstract data typing, then there are better, simpler, more conceptually robust answers than object orientation for that.

> > Just some thoughts. I'm working on a design.
> >
> >
> > Marshall
>
> So, let's just go with Java then? I'm in! Cheers --dawn

Argh ! ;)

Cheers,

  • Tony
Received on Thu Oct 28 2004 - 23:20:44 CEST

Original text of this message