Re: Dreaming About Redesigning SQL
Date: Fri, 24 Oct 2003 11:51:21 -0400
Message-ID: <3520055.1067010681_at_dbforums.com>
Originally posted by Mike Preece
> alfredo_at_ncs.es (Alfredo Novoa) wrote in message
> news:<e4330f45.0310240041.62b42630_at_posting.google.com>...
> > michael_at_preece.net (Mike Preece) wrote in message
> news:<1b0b566c.0310231728.4e643b71_at_posting.google.com>...
> > In my experience this approach is uniformly a disaster.
> Applications
> > are *not* the right place to be enforcing integrity; they
> *cannot*
> > do a decent job of it. Integrity has to be enforced centrally
> and
> > declaratively.
> >
> [end of un-snip]i
> >
> > > Correct me if I have this wrong:
> > > What you're advocating instead is a function of the DBMS. It
> isn't a
> > > function of the Pick DBMS.
> >
> > This is one of the many reasons because Pick is a primitive
> file
> > procesor that does not deserve attention.
> >
> >
> > Regards
> > Alfredo
>
> On the contrary. Enforcing integrity is, in the experience of
> SQL-relational database adherents, of crucial importance. It is not
> important to the same degree in Pick. This is because there are fewer
> tables and fewer pointers between those tables - hence, less critical
> need to maintain their integrity. Where a SQL-relational database has
> pointers to tables containing related data, Pick has the data within
> the same item. Pick is a more sophisticated model resulting in simpler
> databases.
>
> Cheers,
> Mike.
ROFL :o)
-- Posted via http://dbforums.comReceived on Fri Oct 24 2003 - 17:51:21 CEST