At 04:15 PM 5/24/01 -0700, Jason Wharton wrote:

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

There is a simple trick that obviates the need for identifiers. The
basic idea is that here is a single (internal) registry for "tokens"
(cannonical strings). The registry is a simple hash table of known
strings. An arbitrary string is passed into the registry. If it
matches a known string, the address of the string is returned, otherwise
the new string is copied into the registry and its address returned.

All strings associated with database objects (from the parser, meta-
data handlers, etc) are sanitized through the string registry. Two
"tokens", therefore, can be correctly compared for equality by
comparing their addresses. A hash table of object names can be
maintained by taking the address of the tokens mod table size.

The string registry has a huge number of benefits:

1. Each string is represented at most once.
2. Equality comparison are a simple longword compare.
3. Case tweaking is done in one place.

Ditch the ids and go with tokens. Less generated code, faster
execution, less memory used (not that this matters anymore).

I don't think a handful of bytes on a 100 MB ethernet wire is
worth worrying about.

>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/
>>
>>
>
>
>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/
>
>

Jim Starkey