Re: [firebase-br] Diga não às UDFs!

[Jeferson Oliveira]

Olá Daniel!

> O mesmo risco eu corro quando desenvolvo uma aplicação em Delphi,
> bem como poderá acontecer mesmo se eu escrevê-la em C/C++ (exceto
> se eu não usar nada que esteja estaticamente ligado ao SO, o que
> não é muito fácil de se conseguir e ainda assim manter a produtividade).

Concordo. Quando precisei desenvolver aplicações multi-plataforma o
fiz em modo web, com Java e PHP. Desenvolver aplicações desktop
multi-plataforma é uma tarefa à qual não me dispus até então. Tenho me
preocupado mais com a compatibilidade do banco de dados com diferentes
S.O. do que a compatibilidade da aplicação; já que essa última pode
ser contornada, por exemplo, mantendo uma única máquina Windows como
servidor de aplicação acessado por cliente de terminal.


> Bem, quando estou escrevendo uma aplicação em Delphi (por exemplo)
> não tenho recursos como code-template, code-inside, destaque da linguagem,
> etc ao escrever SQL. Afinal a maioria dos comandos SQL que escrevo
> estão dentro de uma string no código-fonte da aplicação, tal como:

Escrevo as sentenças em um editor e após testadas insiro no fonte da aplicação.


> São recursos interessantes, mas nem sempre dispomos deles. Isto ocorre
> principalmente quando temos que escrever SQL para resolver algum
> problema usando apenas um programa como isql.exe. Importante lembrar
> que para maior "compatibilidade" usuários do IB/FB deveriam se tornar
> craques em "isql", pois é talvez a única ferramenta padrão em todos os
> SOs suportados pelo IB/FB.

Concordo com a importância do domínio do ISQL.
Mesmo em modo texto, uma consulta simples como:
select *
from RDB$PROCEDURE_PARAMETERS P
where P.RDB$PROCEDURE_NAME = 'NOME_SP'

lhe retorna todas as informações sobre os parâmetros de uma SP.


> Já passei por este problema, mas não posso culpar o recurso UDF por isto.
> A falha foi minha e coisas deste tipo estão sujeitas de acontecer em tantos
> outros casos, como por exemplo rodar a aplicação com uma versão diferente
> do IB/FB daquela que foi usada no desenvolvimento.

Os problemas que tive também foram por falha humana. Detalhes
importantes não foram devidamente cuidados.
O importante é que detalhes, como versão do módulo que contém a
função, não precisarm ser atentados quando não há utilização de UDFs.
Logo o custo de administração sem UDFs é menor.


> É bom lembrar que a linguagem SQL usada para se escrever STORED
> PROCEDURE no IB/FB é extremamente limitada de recursos. Escrever
> alguns tipos de algoritmos em STORED PROCEDURE pode ser uma muito
> difícil (talvez impossível!) e ainda se corre o risco do desempenho ficar
> ruim
> devido ao modo em que o algoritmo terá que ser escrito.

Sim. Mas, ao que me parece, as UDFs mais utilizadas são as de funções
matemáticas e de manipulação de strings. Que, creio, não apresentarão
muita dificuldade para implementação. Pretendo trabalhar em algumas na
próxima semana e terei uma melhor idéia das minhas limitações na
escrita de algoritmos em PSQL.


Abraço!
Jeferson Oliveira