Re: Multiplicity, Change and MV
Date: Tue, 18 Apr 2006 18:22:47 GMT
Message-ID: <X7a1g.61820$VV4.1154072_at_ursa-nb00s0.nbnet.nb.ca>
B Faux wrote:
> "Bob Badour" <bbadour_at_pei.sympatico.ca> wrote in message
> news:pl81g.61748$VV4.1153485_at_ursa-nb00s0.nbnet.nb.ca...
>
>>x wrote: >> >> >>>"dawn" <dawnwolthuis_at_gmail.com> wrote in message >>>news:1145367130.294647.63460_at_e56g2000cwe.googlegroups.com... >>> >>> >>>>x wrote: >>>> >>>> >>>>>"dawn" <dawnwolthuis_at_gmail.com> wrote in message >>>>>news:1145292548.823950.44180_at_u72g2000cwu.googlegroups.com...
>
> Second, as to Mr Badour's assertion that a 'Pick' database allows users to
> enter anything they want into the database, this is absurd on its face.
> Although the early file systems would support a 'write' function to a
> particular attribute few limitations, it was always incumbent upon the
> application programmer to constrain this ability.
How exactly does the application programmer constrain himself and the DBA who have access to the data without going through any application? Idiot.
The discussion from three years ago, which proved Pick's inherent flaws and the incapacity of Pickies to comprehend them, started from a Pickie's essay with exactly the thesis I gave.
> Any application that
> allows such nonsense would surely suffer a quick and painful death at the
> hands of the first user to whom it is entrusted.
Pick, itself, is exactly an application that allows such nonsense. Sadly, its continued existence disproves your thesis.
> So within an MV DB it would usually fall to the application designer (system
> analyst) to isolate the various expected relationships and address the types
> of cross-functionality desired.
In other words, MV provides no integrity function whatsoever. Here I use MV as equivalent to any NFNF file processor like Pick.
> In an MV DB, the file structure does not
> expose the physical storage
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.
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.
> 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. Received on Tue Apr 18 2006 - 20:22:47 CEST