Re: Table design question

"Mike Sherrill" <MSherrillnonono_at_compuserve.com> wrote in message news:pp7c20dospovtg3vv925vhtrtikgdvm190_at_4ax.com...
> On Fri, 30 Jan 2004 12:46:56 -0500, "Bob Badour" <bbadour_at_golden.net>
> wrote:
>
> >> Try thinking about it this way . . .
> >>
> >> At the conceptual level, a domain is just a data type, and a type is,
> >> among other things, a set of all possible values. One way to handle a
> >> set of values is to store them in a table.
> >
> >It's the "among other things" that kills you. A variable is not a time
> >invariant set of values and their associated operations.
>
> It doesn't kill *me*.

Don't you think it's just a tad anal to nitpick a figure of speech?

> SQL databases don't support domains in the
> relational sense of "domains".

Calling a variable a domain doesn't help that situation any.

> That's why it's often helpful to try
> thinking in other ways.

In what ways are those? Sloppy ways? Careless ways? I would be a lot more receptive to your statement if you gave more outward signs of thought.

> In designing a SQL database based on a logical model, you have to map
> types, relvars, and assignments (among other things) from the logical
> model to features supported by the target platform.

Thus, you are saying that you propose a kludge where a time varying table represents the time invariant set of values of a domain without any provision for the domain's operations. Calling a kludge a domain instead of a kludge neither informs the naive reader nor changes the nature of the kludge.

> This
>
> TYPE USER_ID POSSREP ( INTEGER )
> CONSTRAINT THE_USER_ID IN {1, 112, 314, ... 9997};
>
> (where the enumeration of values is unavoidable)

That's a rather remarkable parenthetical assertion. Care to back it up? Received on Sun Feb 08 2004 - 18:45:25 CET