Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: Avoiding New Fields Causing Ambiguity Errors

Re: Avoiding New Fields Causing Ambiguity Errors

From: Lennart Jonsson <lennart_at_kommunicera.umea.se>
Date: 7 May 2002 14:47:24 -0700
Message-ID: <6dae7e65.0205071347.1b3022d2@posting.google.com>


topmind_at_technologist.com (Topmind) wrote in message news:<4e705869.0205071035.14dc571a_at_posting.google.com>...
> Title: Avoiding New Fields Causing Ambiguity Errors
>
> There is the possibility when adding a new field that an existing
> query(s) in an application(s) might "break" due to field name
> ambiguity being introduced. Other than relying on regression testing,
> approaches to avoid or reduce this include:
>
> 1. Have a systematic way to check for fields with the same name(s) as
> the candidate field(s) already in the schema somewhere. This may lead
> to names like "X_status" and "X_title" instead of "status" and "title"
> where "X" is the table name. (This practice makes queries simpler in
> many cases anyhow.)
>
> 2. Have the query engine *ignore* duplicates by picking the oldest
> table and/or fields, or even have ranks assigned to tables or fields
> in case there is a conflict. This is probably not a perfect solution,
> but may reduce the chances of behavior change. (Of course, this should
> be an optional switch.)
>
> 3. Toss SQL in favor of other relational query languages. (Not likely
> to happen any time soon, but I thought I would include it for the heck
> of it.)
>
> Is there any "best practices" standards that deal with this issue?
>

Best I can think of is to always qualify tabls and columns as in:

select c.name, d.name from myscheme.cars c, myscheme.drivers d ...

just my 3 skr thoughts
/Lennart

> Thanks, -T.O.P.head-
Received on Tue May 07 2002 - 16:47:24 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US