Re: Proposal: 6NF
Date: Wed, 18 Oct 2006 02:21:55 GMT
Message-ID: <7dgZg.154028$1T2.149970_at_pd7urf2no>
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. What's more, I think adding it is just asking for trouble because it multiplies the criteria that one must evaluate a dbms by. (Call me a crank, I fancy myself a humanist - I believe doing that is logical willfulness gone crazy ala Voltaire's Bastards and the book by that title ought to be required reading for all CS students.)
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) and 2) an environment that allows the type or domain support to be created/tested/validated independently of the dbms.
I realize I'm speaking quite loosely here and that there may be neat ways to embed additional type support in a dbms that I haven't thought of. An early bind of type behaviour seems right to me, as once a db is populated, it's usually questionable to change it, whereas much of a dbms's engine is of the late binding kind. That's apart from the language complications, after all, as noted here and elsewhere, a RM dbms at least, doesn't need more than a couple of operators in theory. In practice, it makes sense to have more operators but which are verifiable based on those few. Also, some people point out that one could construct type support code using a RM dbms. Nothing wrong with doing that on paper as it may help QA but in practice I don't think it's very neat.
p Received on Wed Oct 18 2006 - 04:21:55 CEST