Re: Agility and Data Design (was: Dreaming About Redesigning SQL)
Date: 24 Oct 2003 07:11:08 -0700
Message-ID: <1b0b566c.0310240611.1b130a87_at_posting.google.com>
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>...
[un-snip (for context)]
> 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.
Received on Fri Oct 24 2003 - 16:11:08 CEST
