Use long or big decimal. Performance problems will most probably arise elsewhere before you factor a big decimal as the culprit

May be you should start with replacing a = (1/b) * c with a = c/b ? It's not 10x, but still something.

If I were you, I'd create my own class Money, which would keep long dollars and long cents, and do math in it.

From: http://www.javamex.com/tutorials/math/BigDecimal_BigInteger_performance.shtml

Note that a BigDecimal is essentially a wrapper around a BigInteger that "remembers where the decimal point is".

Because of the way we are used to dealing with numbers, as humans, we may have to "think a bit more" when calculating with non-integers by hand compared to integers (e.g. we may have learnt the 7 times table by heart to speed up certain calculations, but probably not the .7 times table). But to a computer implementation, it is essentially no more effort to manipulate non-integers than it is integers, and so on the whole, methods on BigDecimal tend to perform similarly to analogous methods on BigInteger.

BigDecimal is similar to double, it can help maintain precision and is useful for display purposes. Use it only when needed, otherwise double is better for many considerations (memory, performance).

It's useful for instance when storing money values: you want to keep the representation, as well as round the number right when doing sums (additions).

1. What is the difference between BIGINT and LONG on the MySQL level?

   • java.sql.Types.BIGINT is defined as:

     The constant in the Java programming language, sometimes referred to as a type code, that identifies the generic SQL type BIGINT.

     Under Integer Types, the MySQL manual documents that its BIGINT datatype is an 8-byte (i.e. 64-bit) integer. The Java primitive datatype long (and its associated wrapper class java.lang.Long) also represents an 8-byte integer.

     Consequently, as documented under Mapping SQL and Java Types:

     The JDBC type BIGINT represents a 64-bit signed integer value between -9223372036854775808 and 9223372036854775807.

     [ deletia — outdated ]

     The recommended Java mapping for the BIGINT type is as a Java long.

   • There is no LONG constant within java.sql.Types, nor does MySQL have a LONG datatype.

   Which is more ideal for storing currencies?

   Neither. Store the dollar amount as a discrete decimal value using the NUMERIC fixed-point datatype. If you insist on storing the cent amount in an integer type, the "correct" answer depends merely on the anticipated range of values that you wish to support.

2. What would happen if I use PreparedStatement::setLong on a BIGINT column?

   That is exactly how one should set the value of a BIGINT parameter. As documented under java.sql.PreparedStatement::setLong(int, long):

   The driver converts this to an SQL BIGINT value when it sends it to the database.

3. That also begs the question, what happens if I use PreparedStatement::setBigDecimal on a BIGINT column?

   As documented under java.sql.PreparedStatement::setBigDecimal(int, java.math.BigDecimal):

   The driver converts this to an SQL NUMERIC value when it sends it to the database.

   So, Java will send your value to MySQL as a NUMERIC (fixed-point decimal) datatype. MySQL will then perform type conversion as described under Type Conversion in Expression Evaluation: e.g. if you are simply storing the value in a BIGINT column, the value will be cast to a BIGINT for storage. Provided that the value is in range for a BIGINT, you shouldn't notice any ill-effect (except loss of the fractional part).