Re: Argument for 1NF by counter-example
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.
> >
> > 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.
> >
> > 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.
> >
> > 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
> > 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