Actually, I have no idea how this got onto the subject of changing a column
name. That is not an issue in this thread as intended by me, the originator.
I'm only discussing an architectural aspect and not actually trying to
suggest we make changes in Firebird here. I'm quite happy with things the
way they are myself.

I was proposing a way to efficiently allow column names to be longer than 32
characters. If we allowed them to be up to 256 that would be a nice jump but
it would bloat the system significantly since everything is so tied to the
column name instead of just a simple key that stands in for it. It would
also bloat the amount of information that crosses the wire when preparing
statements. I'm not in favor of bloating things and I'm not in favor of
living within narrow constraints either. Something needs to give... That's
when the cost benefit of a layer of indirection is measured. That's all I'm
suggesting be done is to measure the costs.

<on the lighter side>
In Jim's world where the deities do dastardly things on a regular basis the
cosmic occurrences of hardware failure are often enough that you don't rely
on something that requires one step of redirection. But, in a more tranquil
world where the deities efforts are to save and preserve the cosmos I think
introducing one step of indirection for things like descriptive identifier
labels for the outside world to have more efficiency is a step in the right
direction. I guess it boils down to which deity you pay homage to.
</>

Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com

----- Original Message -----
From: "Jim Starkey" <jas@...>
To: <IB-Architect@yahoogroups.com>; <IB-Architect@yahoogroups.com>
Sent: Thursday, May 24, 2001 2:21 PM
Subject: Re: [IB-Architect] Identifier naming woes


> At 04:38 PM 5/24/01 -0400, David Jencks wrote:
> >
> >Does this mean if you remove a column from a table you can break lots of
> >things that depend on it?
> >
> >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.
> >
>
> I think it makes sense to go back to the requirements. Why does
> somebody need to change a name? Certainly requirements change
> that dictate extension of string size or datatype upgrade or
> addition of new fields. But why should a database system go
> out of its way to support a name change?
>
> Jim Starkey
>
> To unsubscribe from this group, send an email to:
> IB-Architect-unsubscribe@onelist.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>