[firebase-br] Formatação é tarefa do aplicativo cliente

[Artur Anjos]

Paulo,

Embora eu concorde que por norma a formatação deverá estar no lado da 
aplicação cliente, existem algumas excepções, e nessas é bom saber as 
possibilidades que existem para a formatação.

Algumas vezes, a formatação não é necessária para mostrar do lado 
cliente, mas para alimentar uma string dentro de uma stored procedure ou 
trigger.

Por exemplo, ao emitir uma factura (nota fiscal), poderemos querer criar 
um lançamento na conta corrente do cliente. Nessa altura, podemos querer 
ter um texto que identifique o lançamento, como por exemplo "N/Factura 
12.431/08'. Neste caso precisamos/desejamos de formatar os campos numero 
(de forma que este tenha o sperador de milhares, por exemplo) e o campo 
ano (de forma a só revelar os dois ultimos digitos).

Isto foi um exemplo. No Firebird, temos que recordar que o "cliente" de 
um select pode ser um trigger, uma stored procedure, ....

Fica aqui as excepções, e a minha humilde opinião. :-)

Artur

Paulo S X Soares wrote:
> Caros colegas,
>
> Estou escrevendo este tópico porque senti a necessidade de opinar sobre uma
> questão que tenho observado frequentemente na lista: o uso do SELECT como
> formatador. Frequentemente aparecem dúvidas como, como formatar uma data,
> como formatar um valor, como concatenar vários campos, como limitar um campo
> varchar, e por aí vai. A minha opinião é de que um SELECT deve ser o mais
> simples possível, respeitando seu objetivo, que é extrair informações
> segundo determinados critérios. Não é função "ideal" do SELECT gerar uma
> lista para ser exibida em um grid ou em um relatório. Se assim o fosse, o
> ANSI SQL já incluiria a definição de todos os recursos necessários para tal
> fim. A sua função básica é, como já disse, extrair informações, estejam elas
> como estiverem. Uma vez que as informações são extraídas e enviadas ao
> aplicativo cliente, este sim tem a tarefa de traduzir (ou formatar) as
> informações para que o usuário as interprete, pois o aplicativo é a
> interface visual entre o usuário e o BD. O SELECT ideal retorna simplesmente
> colunas de tabelas e resultados agregados, sem maiores complicações. Passou
> disso é sobrecarregar o SELECT e o BD.
>
> Essa é a minha humilde opinião quanto à regra. Claro que há as exceções,
> porém estas devem ser consideradas com cautela, que sirvam apenas para
> simplificar, e não para complicar o sistema.
>
> Gostaria de saber o que pensam os colegas.
>
> Obrigado.
>
> ___________________________________
> *** Paulo Sergio Xavier Soares ***
> Skype: Allumo, E-mail: paulosoares.br em gmail.com, MSN: paulosxs em yahoo.com.br
> Consultor em Informatica
> Matematica - UEM
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> Para saber como gerenciar/excluir seu cadastro na lista, use: http://www.firebase.com.br/fb/artigo.php?id=1107
> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>
>