[firebase-br] Dúvidas de estrutura de tabelas /

[Gladiston Santana]

Quem programa delphi e usa tipo currency, real e double tem que se atentar
de que ao transferir seus valores para o banco de dados haverá um
arredondamento implícito se o tipo no banco de dados for diferente da
origem.
Isso é com qualquer banco de dados.
Para não complicar, você precisará compatibilizar Delphi e banco de dados.
Usar numeric(18,4) no banco de dados, mesmo que pareça, não é o mesmo que
currency no delphi. A embarcadero até já mudou em versões recentes do
delphi a forma como essa tipagem funciona para seguir o padrão de mercado.
Eu não recomendo que faça operações que vão lhe resultar em arredondamento
implícito, mas se não tem opcão, recomendo você calcular tudo no BD ou
deixa para fazer todo calculo no lado cliente.
Calcular tudo no BD usando PSQL é bem desafiador, mas tem todo comando que
precisa lá e será rápido, o problema é o tamanho de código, já aconteceu de
eu esbarrar no limite de 64K  e ter que migrar para o lado cliente.
Calcular tudo no cliente envolverá não misturar double com currency, ou é
tudo double ou é tudo currency e em algumas oportunidades usará o comando
valor=RoundTo(valor, -4) para armazenar num numeric(18,4) sem precisar de
conversões implícitas.
Tudo isso que falei só é problema com soma de valores e percentuais que vão
incidindo e calculando até chegar num valor final e cuja auditagem no banco
de dados com comandos SQL tenha de chegar ao mesmo valor. Mas não é um
problema real se o que precisou calcular no lado cliente já tá pronto e o
resto é apenas transferir o resultado para o banco.


Em qui., 23 de jul. de 2020 às 18:04, Luciano Griep <lucianogriep em gmail.com>
escreveu:

> Oi   *Gladiston *
> Obrigado pelo retorno..
>
> (não sei se vou saber responder na thread certa, desculpem qualquer coisa)
>
> Então, sobre o caso um, já está definido que algo será feito, porque esta
> table que comentei CONTAS_PAG_REC deixará de existir,.Agora estamos
> estudando qual a melhor alternativa, se migramos todos os campos de
> vínculos para a nova tabela, se criamos uma tabela separada só para os
> vínculos, ou ainda uma tabela para cada vínculo..
> Eu sou da opinião de criar tabelas separadas para vínculos, já que os
> registros independem um do outro para existir (Exemplo de um vínculo com
> NF, uma NF pode existir sem um Conta Pagar, e uma conta pagar pode existir
> sem uma NF).
> Estamos criando BDs para simular ambos os casos, lotar de dados, e ver
> questão de performance e tamanho final do BD.
>
> Sobre o caso 2, para nós os decimais importam, então smallint está
> descartado, hoje tratamos com até 2 decimais, vou dar uma pesquisada sobre
> float's.
> Sobre o falhar que tu comentou, é poder acontecer de, em uma soma de vários
> registros, ficar em 99,99, ou 100,01?
>
>