Re: Proposal: 6NF
Date: Wed, 18 Oct 2006 02:34:57 GMT
Message-ID: <lpgZg.6964$cz.107564_at_ursa-nb00s0.nbnet.nb.ca>
paul c wrote:
>> paul c wrote: >> >>> Still, the bulk of the apps I've seen >>> don't need that extended type support ... >> >> >> I couldn't disagree with this observation more strongly. Without a rich >> type system, we can't talk about the right things (attributes). If we >> can't talk about the right things, we can't reasonably expect to >> construct proper statements (relations). As well to make assertions >> about horse racing by discussing camels :) And to have a rich type >> system, we'd better make sure the underpinnings are at least consistent >> and preferably correct ;) >> ...
>
>
> I take it you mean "rich type system" to mean "many types". I don't
> object to that. Perhaps my mention of "extended type support" wasn't
> typical usage. I had in mind the extending of one type or another as in
> the polymorphism that oop people talk about. That's what I've never
> seen a big need for.
[voltaire snipped]
> As for adding additional types to an existing dbms the other thing I'm
Yuck! Why would you want to express a concept physically instead of
conceptually or logically?
> not keen on is dbms language support to do that. My attitude is that a
> new type should be created in some language/environment that is more
> apropos to that task and then linked one way or another, with the dbms.
> By 'apropos' I mean two things: 1) something closer to a machine
> language for least execution cost (for example, I think the type support
> code or components ought to decide identity, not the dbms per se)
and 2)
> an environment that allows the type or domain support to be
> created/tested/validated independently of the dbms.
Yuck! Why do you want to do tests blindfolded with one arm tied behind
your back? Would you not want to leverage the power of predicate
calculus for your correctness proofs?
[snip]