Re: Other attributes besides type,precision,scale

"Kenneth Downs" <knode.wants.this_at_see.sigblock> wrote in message news:bunrh2-tc.ln1_at_pluto.downsfam.net...
> I'm curious about the terms used to describe extended properties of a
column
> definition.
>
> In this particular instance, we are flagging that some columns contain the
> value of a URL. The UI code will see this and convert the values to
> hyperlinks where appropriate.
>
> There are a few ways to do this. We might allow a column type called URL
> that is implemented as an x-digit varchar, with various extra validation
> and special treatment by the UI. A data dictionary entry for the table
> might then look like:
>
>
> table vendors {
> column company_name { type: varchar; precision: 40 }
> column website { type: url }
> ...other columns...
> }
>
>
> The other option is to keep the types more pure and add a flag to the
column
> definition, which is then interpreted where appropriate by the various
> tiers, so that we define the column as:
>
> column website { type: varchar; precision: 40; url: yes }
>
> and the table as:
>
> table vendors {
> column company_name { type: varchar; precision: 40 }
> column website
> }
>
>
>
> A first glance reaction might be to say, "nonsense, it's pure UI, keep it
> out of the data dictionary!" But we also define the URL's for XML RPC
> calls in data, and then we define columns in terms of the return values
> from XML RPC calls, so the URL there is part of automated processes, not
> just UI.
>
> Anyway, any thoughts are always welcome.
>

I am not sure I understood your original question. But here goes. Here's what I think:

"Column type" encompasses more than the "form" of the column. It also encompassess something about the semantics of the content. Thus two columns could be required to have exactly the same form, but nevertheless have entirely different content.

In that case, it's entirely valid to have two distinct dictionary entries, each of which specifies the same datatype, precision, and scale, but whose meaning is just plain different.

In my case, I'm accustomed to definining SQL columns in terms of SQL domains, and then possibly referring the domains back to an external dictionary. I'm taking my use of domains to be essentially the same as your use of "column types".

An example of two domains that have the same datatype, precision, and scale, but not the same meaning are extended zip code and social security number. Apart from the placement of spaces or hyphens, they are both nine character strings of digits.
But it makes no sense to refer them both to a single dictionary entry.

Anyway, that's how I see it. Received on Fri Apr 01 2005 - 07:52:00 CEST