On 2001.05.24 14:49:18 -0400 Ann W. Harrison wrote:
> At 10:48 AM 5/24/2001 -0700, Jason Wharton wrote:
<snip>
> Jim and I have argued over this for years. He uses field and table
> names as the primary identifiers of fields and tables.

Are you proposing immutable ids and tracking name -- id correspondence?

That makes
> sense, in a general way. When a table or field is used to define
> or constrain another table or field, its name is stored in the BLR
> that implements the definition or constraint. To the best of my
> knowledge, the vast majority of those dependencies are not tracked.

Does this mean if you remove a column from a table you can break lots of
things that depend on it?
What specifically?

Clearly we need to keep track of all dependencies somehow.

choices are:

use names, and if name changes update all dependent info,

use abstract ids, and have a possible extra layer of indirection
everywhere.

Either way, we need to keep track of the dependency info so if something
goes away we can adjust the state of all dependent objects.

Are there other choices?
So far I lean towards the simplicity of just using names, but I certainly
don't know enough of the internals to make an informed judgement.

david jencks


<snip>