Re: Avoiding New Fields Causing Ambiguity Errors

>> There is the possibility when adding a new field [sic] that an
existing query in an application(s) might "break" due to field [sic] name ambiguity being introduced. Other than relying on regression testing, approaches to avoid or reduce this include: <<

Do the regression testing, or write a tool which will fully qualify column names.

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

This will screw up your data model -- a data element gets its name from what it means LOGICALLY, not where is PHYSICALLY located. Mulitple names for the same data element is a REAAAAALLLLLY bad idea.

>> 2. Have the query engine *ignore* duplicates by picking the oldest
table and/or fields [sic], or even have ranks assigned to tables or fields [sic] in case there is a conflict. <<

You added the new column to the query for a reason (I hope), so you want to see both columns in the results. And -- think about it -- tables cannot have duplicate names in the same schema. So this sentence makes no sense, unless you are deliberately messing up the database for some reason.

Yes, fully qualify the names of coumns when there is a conflict. Use meaningful alias table names in the FROM clause. My personal convention is a one or two letter abbreivation followed by an integer. Received on Tue May 07 2002 - 23:03:57 CEST