Pavel tiene toda la razón, solo me gustaría explicar un poco.
Suponiendo que se refiere a un impacto en el rendimiento en comparación con un punto flotante o un entero de compensación de punto fijo (es decir, almacenar milésimas de centavo como un número entero):Sí, hay un gran impacto en el rendimiento. PostgreSQL, y por el sonido de las cosas MySQL, almacene DECIMAL / NUMERIC en decimal codificado en binario. Este formato es más compacto que almacenar los dígitos como texto, pero aun así no es muy eficiente para trabajar.
Si no está haciendo muchos cálculos en la base de datos, el impacto se limita al mayor espacio de almacenamiento requerido para BCD en comparación con el número entero o el punto flotante y, por lo tanto, filas más anchas y escaneos más lentos, índices más grandes, etc. Operaciones de comparación en b Las búsquedas en el índice de árbol también son más lentas, pero no lo suficiente como para importar a menos que ya esté vinculado a la CPU por algún otro motivo.
Si estás haciendo muchos cálculos con el DECIMAL / NUMERIC valores en la base de datos, entonces el rendimiento realmente puede verse afectado. Esto es particularmente notable, al menos en PostgreSQL, porque Pg no puede usar más de una CPU para una consulta determinada. Si está haciendo una gran cantidad de divisiones y multiplicaciones, matemáticas más complejas, agregaciones, etc. en números, puede comenzar a encontrarse atado a la CPU en situaciones en las que nunca lo estaría cuando usa un tipo de datos flotante o entero. Esto es particularmente notable en cargas de trabajo similares a OLAP (analíticas) y en informes o transformación de datos durante la carga o extracción (ETL).
A pesar de que hay es un impacto en el rendimiento (que varía según la carga de trabajo desde insignificante hasta bastante grande), generalmente debe usar numeric / decimal cuando es el tipo más apropiado para su tarea, es decir, cuando se deben almacenar valores de rango muy alto y/o el error de redondeo no es aceptable.
Ocasionalmente, vale la pena la molestia de usar una compensación de punto fijo y bigint, pero eso es torpe e inflexible. En su lugar, usar punto flotante rara vez es la respuesta correcta debido a todos los desafíos de trabajar de manera confiable con valores de punto flotante para cosas como la moneda.
(Por cierto, estoy muy emocionado de que algunas nuevas CPU Intel y la gama de CPU Power 7 de IBM incluyan soporte de hardware para el punto flotante decimal IEEE 754. Si esto alguna vez está disponible en las CPU de gama baja, será una gran victoria para las bases de datos .)
