Re: Proposal: 6NF
From: paul c <toledobythesea_at_dbms.yuc>
Date: Thu, 19 Oct 2006 00:38:18 GMT
Message-ID: <_NzZg.162307$R63.129956_at_pd7urf1no>
>
> 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.
>
> And the irrationals? Well, if you can figure out how to readily
> make sense of an expression like " 2 < e < 3.14 < pi < 3.15 "
> using the arithmetic hardware that calculates the projections
> needed to render fantasy 3D scenes on your 2D display, you can
> make some BUCKS!
>
> Parsimony, you know... (I am aware of the arbitrary word length
> machines that, for instance, CDC manufactured decades ago. For
> them, 2^^64 was a snap -- but 2^^128 was tough! The limits on
> various machines may be different -- but they're there.)
>
> 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!)
Date: Thu, 19 Oct 2006 00:38:18 GMT
Message-ID: <_NzZg.162307$R63.129956_at_pd7urf1no>
J M Davitt wrote:
> 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.
>
> And the irrationals? Well, if you can figure out how to readily
> make sense of an expression like " 2 < e < 3.14 < pi < 3.15 "
> using the arithmetic hardware that calculates the projections
> needed to render fantasy 3D scenes on your 2D display, you can
> make some BUCKS!
>
> Parsimony, you know... (I am aware of the arbitrary word length
> machines that, for instance, CDC manufactured decades ago. For
> them, 2^^64 was a snap -- but 2^^128 was tough! The limits on
> various machines may be different -- but they're there.)
>
> 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!)
Yeah, I briefly used an IBM 1401 that could easily store a number with 8000 decimal digits. Only trouble was, there was no ram left for anything else.
Still computer inventions can take on a life of their own, eg., the IEEE float spec that encodes a result called NaN (Not a Number) when certain arithmetic results won't fit in the machine's word size. Maybe I'm remembering wrongly but if I'm not, then saying the result is not a number is the same kind of misappropriation that the sql people make when they say CREATE DOMAIN creates a domain!
p
p Received on Thu Oct 19 2006 - 02:38:18 CEST