Re: Multiplicity, Change and MV

Bob Badour wrote:
> B Faux wrote:
><snip>
>
> Bullshit. The meaning of two identically phrased queries changes based
> on whether an access path goes through a file pointer. Any reasonable
> thinking person will understand that as exposing the structure.

Ah, now I know what you are harping on. If I get a chance, I'll write something up about the symmetry that is violated with Pick.

> What's worse, the subtle change in meaning forces casual users to fully
> understand the file structure in order to correctly phrase relatively
> simple queries, which runs contrary to every sound principle of data
> management.

It runs contrary to what the RM does, but that does not make it wrong.

> > Certainly, but a DBA can make any other DB unusable with a single typo too!
>
> A DBA using a relational product can create an incorrect schema.
> However, a DBA using a relational product cannot ever enter data that
> violates the integrity of the created schema. This is a very important
> point when comparing a dbms to a primitive file processor like Pick.

Agreed. There are tradeoffs. We don't often talk about DBA's in MV, but there are often those who work on infrastructure who maintain CRUD services who might or might not be the same developers who write apps. Whether triggers are used or wrapper services for database functions, each site comes up with an architecture. Some are better than others. Some of the features that a SQL DBMS product has are provided by the developers writing database services. --dawn Received on Wed Apr 19 2006 - 14:24:55 CEST