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

Jeferson Oliveira jefersonfoliveira em gmail.com
Sex Out 27 18:34:47 -03 2006


Pha escreveu:

> no DB2 é um pouco diferente, ele já vem
> com as maiorias das UDF que voce precisa

Funções armazenadas é um ótimo recurso. Minha decisão em não utilizar
UDFs está no fato de elas estarem contidas em módulos externos. Os
problemas que citei não ocorrem com funções internas.


> Ná minha opinião o FB deveria restaurar um banco mesmo que as UDF não
> existem, pois o mais importante são os dados.

Sim. E a ausência de um módulo requerido por uma UDF poderia ser
tratada como um "warning" ao invés de ser considerada um erro fatal.


> Voltamos no mesmo caso que falei antes, e se o seu cliente em vez de um SO
> diferente quer um banco diferente, as especificações do projeto e as
> opções do mesmo devem ser discutidas antes do desenvolvimento do mesmo.

É uma decisão de projeto.
Já trabalhei em uma equipe desenvolvendo um sistema multibanco, mesmo
sem ter demanda, pois a diretoria da empresa queria se antecipar às
solicitações do cliente, tendo um diferencial de mercado. Funcionou
bem. Mas enquanto nosso sistema estava cada dia mais compatível com
diversos bancos de dados (Interbase, MySQL, Oracle, SQLServer, Sybase,
e qualquer outro com driver ODBC), nosso principal concorrente, que
utilizava Access que com manutenções preventivas não corrompia, estava
a cada dia oferecendo mais funcionalidades para os usuários do seu
sistema e aumentando sua participação no mercado.

Nos projetos atuais, quando optei por Firebird, levei em consideração
esses pontos. Após alguns estudos, incluindo entrevista com clientes
potenciais, concluí que a grande maioria dos clientes (pelo menos nas
áreas que atuei até hoje) não se importa com o SGBD utilizado pela
aplicação. O que interessa a eles é alta disponibilidade, segurança,
performance.
Por outro lado, em diversas empresas encontramos ambientes diferentes,
com políticas de adminsitração de redes bem distintas; podendo então
encontrar diferentes sistemas operacionais.
Nesse aspecto o Firebird me pareceu uma ótima escolha, já que possui
compatibilidade com vários SOs, é leve e de fácil administração, não
exigindo grande interferência no ambiente computacional.

Minha conclusão, e modelo que proponho, é que políticas de
infra-estrutura são decisões do cliente, logo cabe ao desenvolvedor
ser flexível e tentar adaptar-se à elas, sem perder seus objetivos. A
decisão sobre recursos técnicos utilizados no desenvolvimento do
software (o que inclui a escolha do banco de dados) é uma decisão do
desenvolvedor.

Penso que o cliente deve supervisionar, e exigir, a adequação do
sistema aos requisitos especificados, e avaliar se o resultado final é
o esperado.
Se o resultado final não é o esperado, o cliente deve trocar de fornecedor.
Se o resultado é satisfatório e ainda assim o cliente quiser impor
padrões técnicos aos desenvolvedores, sugiro ao fornecedor considerar
trocar de cliente. :-)


Abraço!
Jeferson Oliveira




Mais detalhes sobre a lista de discussão lista