Re: attribute name conflicts

From: David Cressey <cressey73_at_verizon.net>
Date: Wed, 27 Jun 2007 19:47:03 GMT
Message-ID: <X8zgi.6254$pT4.5769_at_trndny06>


"paul c" <toledobythesea_at_oohay.ac> wrote in message news:Cgwgi.68070$NV3.48265_at_pd7urf2no...
> paul c wrote:
> > I believe Codd originally envisaged "tables" that had what he called
> > domain names to identify "columns" but that in his second paper, he
> > introduced what we know of as attribute names because he wanted, for
> > example, to allow for relations between things of the same type, such as
> > ones used for bills of materials.
> >
> > That's fine as far as single relations go, but it's always led me to a
> > question about a whole database. Does it ever make sense within a given
> > application (as opposed to within a given db) to have two different
> > attribute names that identify different types/domains?
> >
> > (obviously those attribute names would occur in the def'ns of distinct
> > relations.)
> >
> > p
>
>
> 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. Received on Wed Jun 27 2007 - 21:47:03 CEST

Original text of this message