Club Builder

[farag23]

Hola!
Tengo una pequeña duda, y es la siguiente; querría guardar en una bse de datos SQL (uso interbase) un numero real, el cual va a tener como contenido el precio de un artículo en euros, es decir, que quiero que mi número tenga dos dígitos detrás de la coma(decimales) y que se redondee con el tercer dígito; es que veo q cuando guardo un valor en SQL(con el SQL explorer), me guarda una ristra de números que no siempre coincide con el valor que le introduje; por ejemplo:
1,20 me lo guarda como 1.99991110...., lo cual, a la hora de hacer operaciones con ello puede llevar a errores;lo que quería saber es si se puede hacer algo pra que cuando guarde el dato se guarde así, o si, lo tengo que hacer directamente en C++ Builder y guardarlo ya con dos dígitos y redondeado

Muchas gracias
Un saludo

[XyVy]

Si eso me pasaba a mi con los float, pienso que no es recomendable usar un float para campos de tipo precio, si este va a contener decimales, puedes usar varias alternativas, la que yo vengo usando (no es la mejor) es usar un campo entero y en vez de guardar euros (como precio) guardo el valor en centimos, así solo tengo que hacer una ligera conversión cuando paso de centimos a euros y viceversa.

Tienes otra opción que es el usar un campo NUMERIC(e,d) con e cifras a almacenar y d decimales.

[Marky]

Una duda similar tenía yo. Vamos a ver: yo también pretendo almacenar en un campo (paradox) el precio de un artículo. Mi cuestión iba más referida a temas de ahorrro de espacio en disco. Mirando en el SQL Explorer del Builder he visto que el tamaño "físico" de un campo float es de 8 (intuyo que 8 bytes) y eso me ha dejado desconcertado. Como los precios no pasarán de 3 cifras, más dos decimales, se me había ocurrido usar un tipo ftString de tamaño 6 (las tres cifras + la coma + los dos decimales) para ahorra "algo" de espacio. ¿Son paranoias mias?

[XyVy]

Sin animo a molestar Marky creo que lo que dices no te va a mejorar mucho ni tampoco empeorar mucho la primera solución que diferencia hay en almacenar 8 bytes a 6 bytes o quizás 7 bytes, piensa que si lo haces de la segunda manera te ahorras 1 o 2 bytes con respecto al otro sistema y que tendrás que introducir algo de codigo para realizar la conversión.

Supongamos que tienes una tabla con 20 millones de registros y que esa tabla solo tiene un campo de tipo float o bien uno de tipo ftString de 6 bytes. Estamos hablando de un tamaño de tabla de 160 Mb aprox. frente a 120 Mb aprox. si que hay 40 Mb de diferencia, pero sinceramente con 20 millones de registros te diría que cambiaras a un servidor SQL más robusto, pues Paradox imagino que empezará a flojear con esas cifras (esto es un apunte en plan caotico), quizás deberías imaginarte que limites crees que alcanzará la tabla en un periodo proximo de 2 años en cuanto a número de registros y estudiar si realmente te va afectar más la ocupación de espacio en disco o bien el tiempo de introducir ese pequeño calculo de conversión en cada registro por ahorrarte más o menos espacio.

Recuerdo estudiar Oracle y haciamos cosas de esas, pues Oracle hace estimaciones de cuanto va a crecer una tabla para el tema de su paginación interna, no recuerdo exactamente que soluciones tenía en cuenta el gestor, pero lo que quiero decir con esto, es que estudies un poco cuanto crees que va a crecer la tabla, haz una estimación y estudia si realmente supone mucho esos 2 bytes de difernecia frente a introducir un poquito de codigo, a lo mejor ni una cosa, ni la otra es peor ni mejor, pero entonces porque calentarse la cabeza haciendo una conversión si total no es una mejor que la otra, y así si luego cambio y quiero más digitos quizás no tenga que cambiar el codigo.

En fin son pensamientos que me rondan la perola, espero haberte aclarado algo y hacerte reflexionar un poco y por supuesto que puedas tomar una decisión correcta.

Ciao y cuidate.
_________________
OJO!! Ya tenemos subforo de Bases de Datos!!
Gracias a los admins.

[Marky]

Cierto XyVy. Tienes más razón que un santo!! No me había puesto a hacer la cuenta de la vieja. Está clarísimo.

Nos vemos y muchas gracias!

[Invitado]

Si no te interesa mucho el espacio, puedes cambiar tu float por un double y aunque ocupa mas espacio (64) no te modifica en nada la precision.