Re: Proposal: 6NF

Bob Badour wrote:
> paul c wrote:
>

>> Tony D 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.

I don't see any problem with a 'third tuesday' operator or 'third tuesday' result. Why would anybody? I hope this won't get people running to their dictionaries so as to quote definitions for extensible.

> [voltaire snipped]
>
>

>> As for adding additional types to an existing dbms the other thing I'm 
>> 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) 

Yuck yourself. Rubber will meet the road.

>
> and 2)

>> an environment that allows the type or domain support to be 
>> created/tested/validated independently of the dbms.

Nothing wrong with pc, no reason it should be limited to a dbms.

p Received on Wed Oct 18 2006 - 04:47:39 CEST