I'm writing a small application that accesses an SQL database to retrieve information about some local events, including their prices, and allows creation and editing of new events as well as exporting formatted and filtered lists of those events for printing etc.
Now an event may have an entrance fee that is also represented in the data sets (MS SQL Server data type "money"), but I'm wondering which data type to use in my client application.
I know that you should always use Decimal for currency calculations because of its high precision - but I'm not going to do any calculations, it will only get entered as number with two decimal places and stored to the database, and later it gets loaded again and displayed or exported into a printable document - no calculations that could accumulate inaccuracies.
So which data type would you use in this case? Still go for Decimal just because it's money and don't care about the memory etc? Or use Double instead as it would be precise enough? Alternatively I could probably store the price in Cents as Integer as well. What type should I go for?
Generally when dealing with existing data source, just follow what's already used. In this case, SQL Server .NET reader maps money to decimal. This means no awkward casting and nothing wasted in transmission.
TomTom's answer in his comment point the case when double can get the performance you needed with acceptable precision, but unless you're dealing with millions of calculations or starved in storage there's no reason to not use decimal for financial data.