Re: By The Dawn's Normal Light

From: Dawn M. Wolthuis <dwolt_at_tincat-group.comREMOVE>
Date: Tue, 26 Oct 2004 16:05:56 -0500
Message-ID: <clme7u$c0d$1_at_news.netins.net>


"Bill H" <wphaskett_at_THISISMUNGEDatt.net> wrote in message news:cdyfd.310369$MQ5.86568_at_attbi_s52...
> Marshall:
>
> "Marshall Spight" <mspight_at_dnai.com> wrote in message
> news:ZMxed.303809$D%.296516_at_attbi_s51...
> > "Dawn M. Wolthuis" <dwolt_at_tincat-group.comREMOVE> wrote in message
> news:clc0k2$ed1$1_at_news.netins.net...
> > >
> > > There are two types of collections -- "files" and "nested lists". The
> > > nested lists may have one or more attribute types and zero to many
> attribute
> > > values. Whether the user cares about the ordering or not, the
database
> > > orders these, while the files are keyed, and therefore logically
> ordered.
> > > So, both top level structures (files) and their substructures are
> logically
> > > ordered.
> >
> > It's funny: the RM has no facilities for handling lists; the Pick model
> > has no facilities for handling relations.
>
> If I'm not mistaken the definition that started this thread was corrected
to
> state:
>
> "A relation is in 1NF if and only if all underlying domains contain atomic
> values only."
>
> I must say, a "relation" certainly exists in the Nelson-Pick model. There
> are tremendous facilities to handle both "relations" and "lists".

Yes, the files are relations, by the standard mathematical def of a relation. Because the metadata (including database schema names and types) do not prescribe, but describe, data and there may be multiple such descriptions of the same data, there are likely some defs of relation in the db world that would not permit pick files to share that description.

> > Sometimes you have ordered data, and sometimes you have unordered
> > data. Which primitive operations you want depends on which one
> > you have. Each model handles one well and ignores the other.
>
> Everything I've seen in the Nelson-Pick model showed me there are
facilities
> to handle ordered and unordered data and provide functions to move between
> "relations" and "lists". Their method reminds me of "piping" on other
O/Ss:
> create a list and "pipe" each item to another process.
>
> > I propose that the ideal model would handle both, and have
> > relatively simple ways of transforming one into the other.
> >
> > Lists are simpler and sometimes therefore the better choice.
> > Relations are more powerful, but that can mean more
> > complexity than you need.
>
> Jeeze, and to think, all I'm looking for is what works and doesn't take me
3
> IT staff to keep it going. :-)
>
> Bill

And you figured it out -- using Pick rather than an RDBMS does seem to give a significant bang for the buck to a company. Cheers! --dawn Received on Tue Oct 26 2004 - 23:05:56 CEST

Original text of this message