Re: attribute name conflicts

David Cressey wrote:
> "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

>>>up).  NAME might refer to a City's name in one context,  and airline's

>>>in another context,  and an airport's name in a third context.
>>>These columns all had the same datatype and precision  (CHAR(20)) so

>>>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 think that's what I meant (I often forget to distinguish between the SQL use and what people like D&D mean by domain). From what little I've been able to find out, it seems that when JOIN is involved, some SQL's are quite happy to try to coerce a "CHAR(20)" to, say, an INTEGER.

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

No, I guess not, but thanks for that and I'm sure you are accurate as far as what goes on in most bureaucracies. I guess "types" such as INTEGER have traditionally been a way for people to tell a dbms, aka machine, how to manipulate values and this might have distracted them from thinking through the effects different types for the relational operators. Not being a data modeller I've probably been unfair to accuse them sometimes of chasing their tails but I'm not so sure that accusation wasn't accurate!

> 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 - 17:49:26 CEST