Re: Field naming: Same name represents different data

"- g r e g -" <gwarnick_at_fhcrc.org> wrote in message news:3E5A6E90.8060409_at_fhcrc.org...
> BB,
> Sure, I think that users understand the difference here, but that it
> would be bad practice because there exist other options that are less
> confusing. Instead of calling them all AGE, Why not call the domains
> EmpAge, AccRcvAge, CheeseAge?

Why? Users wouldn't call them that and the names are simply redundant: employee.empage, accounts_receivable.accrcvage, and cheese.cheeseage.

> In my experience, clarity is much more
> valuable than typing time.

What clarity, though? How is it clear to the accounts receivable user that they should prepend accrcv in front of every name?

> When you plan out your
> scope and schema for a DB, would you ever plan to have different
> tables have the same variable names for non-key/foreign key domains?

I am not sure I understand your question. Do you mean like having a manager attribute referencing employee in both a department relation and a works_for relation? Yes, I would do that. Might I have a manager attribute in another relation with a different domain and referencing a different relation? Yes, I might.

> There may be reasons for naming as described, but generally its easier
> to work with a system with unique names, as in when doing a complex
> join or creating a UML diagram.

I might suggest that your UML diagramming tool imposes needless naming constraints. And natural join works best when the likely joined attributes have the same name.

> Please let me know your thoughts.
> Thanks, Greg
>
>
> Bob Badour wrote:
> > Why would it be bad practice to use the user's preferred terminology?
Users
> > understand that the age of an employee is different from the age of a
> > receivable is different from the age of a block of cheese. Don't they?
> >
> > "- g r e g -" <gwarnick_at_fhcrc.org> wrote in message
> > news:3E5A58D7.6090200_at_fhcrc.org...
> >
> >>While not great practice (I'd be frustrated) I don't know of any rule
> >>that says that it cannot be done. There may be an internal procedure
> >>at your office/site that precludes one from creating in one database
> >>two different 'meanings' for the same named domain. But, off the top
> >>of my head, if you run a cheese ordering buisiness, you might have a
> >>database where the domain named AGE in one table contains the value of
> >>a cheese-maker's age code, while another table flags boolean values
> >>for a past due bill into the domain AGE. Yeah, its silly and surely a
> >>bad practice, but not against the rules, I believe.
> >>Greg
> >>
> >>
> >>Lee C. wrote:
> >>
> >>>I am still fairly new to database design and analysis. I have just
> >>>come across a database that frequently uses the same field name to
> >>>represent different data (data that would be from different domains).
> >>>When tablename.fieldname is considered, of course, the names are
> >>>unique. I thought there was a general rule about this, but cannot
> >>>find any relevant information. Can someone please point me directly
> >>>to an online source that will help me to understand this?
> >>>
> >>>Thanks.
> >>
> >
> >
>
Received on Tue Feb 25 2003 - 08:24:20 CET