Re: attribute name conflicts

"paul c" <toledobythesea_at_oohay.ac> wrote in message news:P2Agi.68285$NV3.22266_at_pd7urf2no...
> David Cressey wrote:
> > "paul c" <toledobythesea_at_oohay.ac> wrote in message
> ...
> >>Oops, sorry about that, I meant to ask: Does it ever make sense within a
> >>given appl'n to have two different relations that use the same attribute
> >>name but with different types?
> >>
> >>p
> >
> >
> > I'm not sure it makes sense, but I once saw a database where lots of
> > different entities had a column with the name "NAME". (I am not making
this
> > up). NAME might refer to a City's name in one context, and airline's
name
> > in another context, and an airport's name in a third context.
> > These columns all had the same datatype and precision (CHAR(20)) so
this
> > may not be a case of what you are describing.
>
> I have too, along with the name "ID", especially in non-relational, or
> should I say non-sql db's.
>
> This reminds me that I've seen the so-called "user types" of some sql
> products criticized because they weren't anything more than aliases, but
> I sometimes wonder if any products actually allow you to name a type (if
> not its values and operators) and say also that for entry purposes it is
> of type CHAR{20} but that for identity purposes, eg., when joining, it
> is of the named type, eg., "CITYNAME".
>

I'm not sure, but I think the "user types" you are referring to are the same thing as what I would call "user defined domains". The SQL Syntax would be:

CREATE DOMAIN CITYNAME CHAR(20); Now the name CITYNAME can be used in a column definition, to propagate the properties of the domain on to the column.

The first relational DBMS I dealt with, DEC Rdb/VMS had these. When used properly, they could be an enormous assistance to data management at the metadata level. Basically, stating that two columns (from the same table or different tables) are based on the same domain can say something very useful about both the syntax and the semantics of the data, without having to write a book about it.

User defined domains basically allow the system tables of a database to function like a mini data dictionary. The domains can be hooked up to a "real data dictionary" (active or passive), and from there the data can be connected to other data across the enterprise.

Like any tool, user domains can be used obtusely or perversely. I've seen uses of user domains that either illustrate the author's basic confusion about the data itself, or represent a sadistic attempt to make the system harder for the next person to learn.

But they are a good tool, in the right hands.

Are user domains the same thing you were referring to?

The generic "ID" column is a whole other can of worms. This can mean very different things to different practitioners. Received on Thu Jun 28 2007 - 12:51:01 CEST