Fixed-point DECIMAL representation in the database is just as good as storing Bitcoin values as integers. Baked into the field definition is the amount of precision. And Python and other languages have features to work with fixed-point numbers. This approach relieves the mental overhead and complexity of converting to integers (which might overflow a 32-bit int) and back all the time.
I just looked this up (feel free to correct me if you think I've missed something): the value field in a TxOut is a 64 bit unsigned integer. It's true that by convention the unit is 1e-07 BTC (i.e. a decimal fraction), but nothing in the protocol actually cares, the "decimalness" is just in what you call it. Implementing this with decimal math is just wrong, and likely to break your implementation due to subtle bugs. Storing it in a database as a decimal fixed point is plausible as it prints nicely, but in no way would I consider that choice "just as good as" a quantity that was designed to fit in a native machine word.
Yes, the internal representation of Bitcoins is the 64-bit unsigned INT, but I'm talking about storing customer account balances, trade prices, etc. I would not use DECIMAL if I were writing an alternative client for Bitcoin or for some other software that must create network transactions at a low level.
Even the RPC protocol for the main Bitcoin client returns fixed-point numbers and expects non-integers for input arguments [1].
But I think we can all agree that using FLOAT for this kind of thing is just plain wrong.
(Ironically this is exactly what I was doing as the language I was using didn't/doesn't [actually rather annoyingly] support decimal types natively so I have various currency types which have different levels of precision and I store BTC as "natively" as possible). That and my code never progressed terribly far and it would have had many more (qualified) eyes looking at it from a number of angles (security, financial data, integrity, replication, etc) before it would've touched the Internet.
