Re: Proposal: 6NF
From: J M Davitt <jdavitt_at_aeneas.net>
Date: Thu, 19 Oct 2006 00:10:18 GMT
Message-ID: <KnzZg.17032$pq4.16613_at_tornado.ohiordc.rr.com>
>>paul c wrote:
>>
>>>David Cressey wrote:
>>>
>>>
>>>> ...
>>>>
>>>>
>>>>>PMFJI, when it comes to a dbms engine, I don't know the difference
>>>>>between a type and a domain.
>>>>>
>>>>
>>>>In the context of a dbms engine, a type would be the built in datatypes
>>>>that the engine supports, like INTGER, DECIMAL, CHAR, and DATE, and also
>>>>the builtin functions and operations, like "+" or "weekday(x)".
>>>>
>>>>A domain would be what you get when you say CREATE DOMAIN. It's a
>>>>set, but
>>>>it has no functions and operations other than the ones it inherits
>>>>from the
>>>>data type it is based on.
>>>>
>>>>Does this make sense?
>>>>
>>>
>>>Ièd say YOU make sense, but IT doesnèt. However, if the difference you
>>>mention is typical usage, I guess Ièll have to accept it. I vaguely
>>>remember using something like CREATE DOMAIN in SQL, perhaps that is
>>>exactly what I used, and being disappointed - I seemed no more than a
>>>name aliasing operator.
>>>
>>>p
>>
>>There's lots of potential confusion, here. The D+D crowd
>>can be expected to say, "Wait! The only types that should
>>be built-into a dbms are boolean, tuple, and relation."
>>Their view is that *users* should be able to specify what
>>integers, rationals, strings, dates, gender, countries,
>>currencies, etc., etc. the database should be able to handle.
>>And, by handle, I mean represent, store, and operate upon.
>>
>>In that regard - and, acknowledging that dbmses are limited
>>to what computers are capable of representing - types and
>>domains are the same thing. Types and domains are *not*
>>what SQL says you get after CREATE DOMAIN, and operations
>>must (generally) be defined independently of types --
>>although, of course, types must be extant before operations.
>>
>>The "what computers are capable of representing" remark is
>>important: while we might describe the set of, let's say,
>>"extended integers" as "zero and naturals and negative naturals
>>and infinity and negative infinity," it's obviously impossible
>>to represent many of those values using computers.
Date: Thu, 19 Oct 2006 00:10:18 GMT
Message-ID: <KnzZg.17032$pq4.16613_at_tornado.ohiordc.rr.com>
dawn wrote:
> J M Davitt wrote: >
>>paul c wrote:
>>
>>>David Cressey wrote:
>>>
>>>
>>>> ...
>>>>
>>>>
>>>>>PMFJI, when it comes to a dbms engine, I don't know the difference
>>>>>between a type and a domain.
>>>>>
>>>>
>>>>In the context of a dbms engine, a type would be the built in datatypes
>>>>that the engine supports, like INTGER, DECIMAL, CHAR, and DATE, and also
>>>>the builtin functions and operations, like "+" or "weekday(x)".
>>>>
>>>>A domain would be what you get when you say CREATE DOMAIN. It's a
>>>>set, but
>>>>it has no functions and operations other than the ones it inherits
>>>>from the
>>>>data type it is based on.
>>>>
>>>>Does this make sense?
>>>>
>>>
>>>Ièd say YOU make sense, but IT doesnèt. However, if the difference you
>>>mention is typical usage, I guess Ièll have to accept it. I vaguely
>>>remember using something like CREATE DOMAIN in SQL, perhaps that is
>>>exactly what I used, and being disappointed - I seemed no more than a
>>>name aliasing operator.
>>>
>>>p
>>
>>There's lots of potential confusion, here. The D+D crowd
>>can be expected to say, "Wait! The only types that should
>>be built-into a dbms are boolean, tuple, and relation."
>>Their view is that *users* should be able to specify what
>>integers, rationals, strings, dates, gender, countries,
>>currencies, etc., etc. the database should be able to handle.
>>And, by handle, I mean represent, store, and operate upon.
>>
>>In that regard - and, acknowledging that dbmses are limited
>>to what computers are capable of representing - types and
>>domains are the same thing. Types and domains are *not*
>>what SQL says you get after CREATE DOMAIN, and operations
>>must (generally) be defined independently of types --
>>although, of course, types must be extant before operations.
>>
>>The "what computers are capable of representing" remark is
>>important: while we might describe the set of, let's say,
>>"extended integers" as "zero and naturals and negative naturals
>>and infinity and negative infinity," it's obviously impossible
>>to represent many of those values using computers.
> > > A nit, perhaps, but which values would those be that we cannot > represent with computers? > --dawn >
Well, the line must be drawn between what can and cannot be easily represented. For instance, it would be tough to handle integers in the intervals (-oo, -2^^64] and [2^^64, oo). (Did I get that right?) And there's a whole world-full of values that slip between one easily representable rational value and the next.
Ultimately, though, my statement stands: there ain't enough RAM anywhere (or everywhere?) to hold the bits necessary to count half way to oo. (I know: cite absorption and say, "Wrong! oo!) Received on Thu Oct 19 2006 - 02:10:18 CEST