Avoiding New Fields Causing Ambiguity Errors

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?

Thanks, -T.O.P.head- Received on Tue May 07 2002 - 13:35:49 CDT