Re: Proposal: 6NF

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
> >

>

I was just calling you on the "it's obviously impossible to represent many of those values using computers" line, which says nothing about "easily" nor about representing them strictly with digits, for example.

> For instance, it would be tough to handle integers
> in the intervals (-oo, -2^^64]

This sentence I am typing represents one integer in the above interval, even if it is not explicit which one (of course the one on the right end point has already been represented by you above).

Note: This would just be a terminology nit except that when talking about types, strong typing in a DBMS sometimes encourages developers to encode legitimate values for an attribute in a way that aligns with a type, such as integer, when extending the type to include the value would be both unusual and painful. That is how you get all 9's in dates or integers, then all 8's when the 9's have been used, to represent something that should be a strong. -2^^64 could be permitted as a string representation of an integer if the type would permit it. Of course if it needed to be interpreted and used by the computer and not just a human (which was your intent, I think), there would certainly be issues in encoding it this way.

Every typical value in a database is either a String representation of a value or a binary-encoded value. For standard business databases, if every type, including integer, were to extend String, there can be some advantages. I realize this is a digression, sorry.

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

>

Agreed. Again, I was calling you on the statement about representation. I can represent pi here exactly as you did in the above paragraph. It, like all other numbers, can be represented as a string.

> 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.)

>

I do understand what you were saying, I just thought I'd call you on your "representation" statement. cheers! --dawn Received on Thu Oct 19 2006 - 03:08:46 CEST