Firebird e valores monet�rios

Question

J� li v�rios textos � respeito do assunto e ainda tenho d�vidas. At� agora sempre usei DOUBLE PRECISION no IB/FB para simular campos monet�rios, mas j� ouvi falar que � melhor NUMERIC/DECIMAL para evi...

Vinicius2k · Answer

Eu nunca tive problemas com DOUBLE PRECISION porque sempre usei NUMERIC e, com este, nunca tive problemas.

Quando poss�vel, eu utilizo no m�ximo NUMERIC(9,e) para que o IB/FB utilize o tipo INTEGER para armazenar o dado, economizando (eu acho) tamanho do registro, j� que a partir de NUMERIC(10,e) ele ir� utilizar INT64 internamente.

Nunca tive problemas de arredondamento e de incompatibilidade, apesar de TFmtBCD ter me dado �algum trabalho� no in�cio (com dbExpress).

Creio que muitas vezes os problemas com DOUBLE e NUMERIC podem ser evitados. Por exemplo, na aplica��o, eu nunca fa�o CAMPO_1 := CAMPO_2 * CAMPO_3. Eu procuro j� tratar o arredondamento correto dentro da aplica��o. Algo como: CAMPO_1 := ROUND(CAMPO_2 * CAMPO_3, 2), fazendo com que o campo j� receba o valor da forma correta.

Se vc tamb�m utiliza esta pr�tica, pode ser esta a raz�o de nunca ter tido problemas com DOUBLE, j� que todos reclamam, deve mesmo ser ruim sem o tratamento adequado.

T+

Afarias · Answer

como pode ser visto no post abaixo://forum.clubedelphi.net/viewtopic.php?t=69062&highlight=floatTipos de ponto-flutuante s�o um �problema� em geral para a computa��o, n�o importa o banco de dados, sistema operacional ou o q for.Tipos como FLOAT ([url=//www.math.grin.edu/~stone/courses/fundamentals/IEEE-reals.html]IEEE[/url] single precision: 7 d�gitos) ou DOUBLE PRECISION (IEEE double precision: 15 d�gitos) s�o por natureza �imprecisos�.Para valores monet�rios e outros situa��es q exigem precis�o (e geralmente poucas casas decimais) diversas solu��es s�o abordadas como a ado��o de tipos inteiros ou [url=//en.wikipedia.org/wiki/Binary-coded_decimal]BCDs[/url] para representar valores de ponto-flutuante No Interbase/Firebird, os �tipos� NUMERIC/DECIMAL n�o representam TIPOS reais mas apenas uma dessas solu��es mencionadas acima.O IB/FB determina a [melhor] forma de armazenamento do NUMERIC dependendo da precis�o (�tamanho m�ximo�) do valor e do dialeto da base.Para bancos no dialeto1 uma precis�o at� 9 � suportada como INTEGER internamente, provendo valores representados perfeitamente. J� no Dialeto 3, com o �advento� do INT64, � suportado at� uma precis�o de 18� uma boa pr�tica *sempre* usar NUMERIC, a n�o ser q realmente seja desejado/necess�rio um campo de ponto-flutuante (FLOAT ou DOUBLE)T+...

Afarias · Answer

Ah, e quanto ao Currency do Delphi, � mais uma solu��o dessas ... o Currency serve para representar valores de campos flutuante (at� 4 casas decimais) mas � um INTEIRO

(Obs: o Delphi n�o implementa um tipo BCD, at� onde sei)

T+

Gandalf.nho · Answer

E qual precis�o devo usar? Alguns falam em (18,2), outros em (14,2) ou (9,2). A maioria dos meus c�lculos envolvendo valores monet�rios geralmente s�o simples somas ou subtra��es, raramente preciso trabalhar com divis�o ou multiplica��o. D� para converter sem problema um campo DOUBLE PRECISION (j� populado) para NUMERIC/DECIMAL?

Afarias · Answer

|E qual precis�o devo usar? Alguns falam em (18,2), outros em (14,2) ou
|(9,2).

N�o existe uma precis�o melhor q outra. No dialeto 1 o melhor � usar no m�ximo 9, j� no dialeto 3 pode usar at� 18.

N�o tem f�rmula aqui, use a maior precis�o q acha q vai precisar. Exemplo: se para um determinado campo o valor m�ximo extrapolando tudo � 9 milh�es, e ele � monet�rio (2 casas decimais) ent�o vc usaria um campo NUMERIC(9,2) -- sendo assim: 9.999.999,99

(veja q esse n�mero n�o � o m�ximo real, apenas o m�ximo admitindo a precis�o e escala)

|D� para converter sem problema um campo DOUBLE PRECISION (j�
|populado) para NUMERIC/DECIMAL?

Se vc n�o tem problemas no uso de DOUBLE n�o acho q deve ficar preocupada em migrar o q j� existe. Mas se for migrar, esteja atenta para ver se a convers�o foi ok

T+

Vinicius2k · Answer

[quote:fa042ea8f0=�afarias�](Obs: o Delphi n�o implementa um tipo BCD, at� onde sei)[/quote:fa042ea8f0]Anderson,N�o implementa mesmo ou vc acha que a implementa��o � ruim?Pergunto pois, at� onde eu sei, a partir do Delphi 6 a implementa��o j� existe, inclusive utilizada no dbExpress. A unit da implementa��o � a �FMTBcd�.[quote:fa042ea8f0=�afarias�]N�o tem f�rmula aqui, use a maior precis�o q acha q vai precisar. Exemplo: se para um determinado campo o valor m�ximo extrapolando tudo � 9 milh�es, e ele � monet�rio (2 casas decimais) ent�o vc usaria um campo NUMERIC(9,2) -- sendo assim: 9.999.999,99[/quote:fa042ea8f0]Concordo. Creio que a precis�o escolhida n�o tem influ�ncia no resultado final de opera��es matem�ticas porque o dado � armazenado como INTEGER. Acho que apenas seguir a regra �b�sica� de n�o criar campos maiores do que se precisa � suficiente. Como disse anteriomente, quando poss�vel eu uso at� NUMERIC(9,e) para que o IB/FB n�o precise utilizar INT64 para armazenar o dado. Mas se n�o for poss�vel, de NUMERIC(10,e) em diante eu uso muitas varia��es, dependendo do caso.T+...

Afarias · Answer

|N�o implementa mesmo ou vc acha que a implementa��o � ruim?

N�o implementa. Bom, mas pra ser mais exato ...

N�o implementra um tipo BCD (Decimal) nativo!

O TBCD � um registro usado para representar um n�mero BCD (vindo de um banco de dados por exemplo). O TBCDField por exemplo pega esse numero BCD e ent�o transforma internamente em um Currency (Bin�rio) para manipular (c�lculos, etc) e converte novamente para a representa��o (TBCD) quando tem q enviar de volta para o banco.

� verdade q no D6 em diante (meu Delphi � o 5 ainda) h� mais fun��es para trabalhar com TBCDs, mas ainda para isso (a melhor forma) � usar Variants.

Ent�o, o fato �: O Delphi n�o possui um tipo BCD *nativo* :)

Para manipular n�meros mesmo no c�digo (c�lculos e tals) vc tem/deve mesmo usar Currency

Valeu pela observa��o! Abra�o

T+

Gandalf.nho · Answer

Bem que o Firebird podia implementar um tipo monet�rio nativo, como outros bancos tem (at� o Paradox e o Access tem...). N�o sei como � em rela��o aos outros bancos cliente/servidor...

Afarias · Answer

|Bem que o Firebird podia implementar um tipo monet�rio nativo

Mas essa � a fun��o do NUMERIC.

N�o necessariamente tem q se usar um BCD, o q importa � o resultado n�o? Acho a solu��o de usar ponto-fixo (fixed-point decimals) muito boa.

T+

F�rum Firebird e valores monet�rios #53382