Re: MV counterexample

From: Anthony W. Youngman <wol_at_thewolery.demon.co.uk>
Date: Thu, 6 May 2004 23:00:24 +0100
Message-ID: <JgK1THB4VrmAFwZq_at_thewolery.demon.co.uk>


In message <4099fc71_at_post.usenet.com>, x <x-false_at_yahoo.com> writes
>**** Post for FREE via your newsreader at post.usenet.com ****
>
>
>"Karel Miklav" <karel_at_inetis.spppambait.com> wrote in message
>news:c7cmao02o3q_at_enews4.newsguy.com...
>> my point was, there is no inherent structure in data. We treat
>> characters in a string and numbers in an array like they are somehow
>> connected by invisible ties which preserve their order/structure, but
>> they're not, they're only conencted in our haeds. There are reasons to
>> optimize, but the structure is not one of them, rather a way.
>
>So you say that each "atomic" piece of data is (should be) self contained ?
>Is this possible ? Wouldn't we end up with one big chunk of data ?
>Or do you argue that all integrity constraints should belong to user space
>(in the user schema or in the user application) ?
>
define "atomic" :-)

define "user space" (as in schema or application :-)

Bearing in mind that apparently, in order to have real data integrity, we need user-defined primary data types, how on earth is that going to be PRACTICAL without pushing at least some integrity checks into user-space.

A database relies on metadata to do integrity checks. Certainly with current RDBMSs, a major function of analysis is to convert metadata into data. Without some way of converting that data back into metadata (ie giving the user the ability to modify the operation of the database engine) there is no way the dbms is going to be able to apply any integrity check that relies on that sort of (meta)data.

Cheers,
Wol

-- 
Anthony W. Youngman - wol at thewolery dot demon dot co dot uk
HEX wondered how much he should tell the Wizards. He felt it would not be a
good idea to burden them with too much input. Hex always thought of his reports
as Lies-to-People.
The Science of Discworld : (c) Terry Pratchett 1999
Received on Fri May 07 2004 - 00:00:24 CEST

Original text of this message