PC Toledo

Normalmente, funções muito complexas são implementadas no Firebird (e em outros SGBDs) em nível de UDF. Se esta não for bem escrita até pode causar uma perda de performance, realmente. Mas chaves (relativamente) complexas fazem parte do cotidiano desse tipo de SGBD. Como ele roda num servidor, normalmente a indexação é muito rápida, mesmo com um volume elevado de dados.

Por outro lado, a indexação do DBF é sempre local, o que significa fazer trafegar todos os 100.000 registros pela rede. A chave de indexação em si nem seria tanto o problema, já que ela é executada rapidamente. O problema é o tráfego. Daí será sempre muito lento, dependendo do tamanho do registro. Claro que há casos em que uma chave MUITO complexa pode ajudar a tornar tudo ainda mais lento. Convém não abusar. Mas se o camarada precisa dessa chave, fazer o quê (exceto chorar)? ))

fazer o quê (exceto chorar)? ))

Pois é, tudo merece um bom planejamento. Inclusive em se tratando de bancos pequenos, aliás uma hora eles podem ficar grandinhos.

Pelo menos pessoalmente, mesmo já fazendo meus testes com MySql, ainda me sinto um pouco preso aos atributos dos DBF´s.
Quando se trabalha com bases de dados relacionais, temos que explorar o porquê destes bancos terem sido desenvolvidos. Justamente livrar a estação de trabalho de fazer todo o trabalho pesado. Deixar este trabalho pesado ( filtros, relacionamentos, etc...) para o servidor fazer, e te devolver apenas o que voce quer realmente. É um tanto dificil de compreender e talvez implementar, mas se queremos explorar tudo o que estes bancos de dados, podem nos oferecer, a primeira coisa é compreender o porquê eles foram desenvolvidos.

Até se acostumar leva um tempinho. Por isso é preciso ler bastante a respeito de tudo que se refere ao planejamento que você comentou. Inclusive com relação a uma possível migração futura pra outro banco (abstração).