--- In firebird-support@yahoogroups.com, "Adam" wrote:

>>> (http://groups.yahoo.com/group/firebird-support/message/56457)
>>
>> Sorry to disagree, and I guess it is also a matter of taste,
>> but I am very opposed to introducing redundancy into a database.
>> It can lead to inconsistencies. This 'good technique' is what I
>> would prefer to call a kludge.
>
> Call it what you want, it is no more "redundant" than an index. I
> would certainly consider it an "overhead", but there is nothing
> kludgy about it.

I guess I overacted. It's not pretty, but you take what you get.

>>> That means
>>> that a normal index on a field qty could not help you run the
>>> following
>>>
>>> select max(qty) from tablea
>>
>> Isn't an index a B*-Tree, so that all you have to do when finding
>> the maximum is to descend from each parent node to the leaf node
>> that contains the largest values?
>
> Sort of, IBPhoenix has a few excellent articles on the nitty gritty
> details of Firebird that can help you.
>
> (http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_expert1)

The article did not make it clear to me why a SELECT MAX() could
not profit from an ascending index.

> Out of interest have you taken a look at Firebird 2
> (it is alpha, not production ready). There are certainly good
> reports on the performance front.

My company wants to choose the database most suited for its needs
and intends to start using it this year.
Alpha and Beta releases are out of the question, and I didn't
have the time to look at Firebird 2.

Thank you,
Laurenz Albe