+1  A: 

For 4 decimal places, use money if you can

Reason: it's faster then decimal but is exact

Money, float, decimal article

Edit: based on comment

Interesting argument. I follow both blogs.

Note the examples here: different precision based on datatypes and precedence

declare @d decimal(19,4), @ddiv decimal(19,4)

set @d = 12.39
SET @ddiv = 1000

select (@d/@ddiv)*@ddiv, (@d/1000)*1000
--Gives   12.390000    12.390000000

Explained by my answer here to "T-SQL Decimal Division Accuracy"

Now, this is interesting. Decimal, different answers

declare @d decimal(19,4), @ddiv decimal(19,4)

set @d = 12.39
SET @ddiv = 1001

select (@d/@ddiv)*@ddiv, (@d/1001)*1001
--Gives   12.390000    12.389999622

Back to money: same answer for each

declare @d money, @ddiv money

set @d = 12.39
SET @ddiv = 1001

select (@d/@ddiv)*@ddiv, (@d/1001)*1001
--Gives   12.3123    12.3123

Moral: store in SQL, process in client languages...

gbn
Thank you for the link. However, I'm a bit wary of the money datatype due to alleged inaccuracies as discussed here: http://groups.google.com/group/microsoft.public.sqlserver.programming/browse_thread/thread/a4101df9f779d166/af6861dc4d5e0705?#af6861dc4d5e0705
Stephan Keller
I played around with your examples (thanks, btw), and the lesson I learned is "do not use literals" :) . I am still on the fence regarding the money vs decimal thing, though.
Stephan Keller
Personally, I'd go for money for performance and efficiency if you can offload your maths into the client. I use decimal(19,6) generally if I have any processing to do: I want to avoid precison/scale issues so I keep it all the same.
gbn
Guess I will go with decimal(19,6) then. Since it seems to be the same performancewise I will at least be covered if the customer needs to raise the scale or precision.
Stephan Keller
+1  A: 

The main reason to use a smaller data precision, despite using the same amount of storage space, is to convey meaning to future users of the system. Which is also why it's important to use appropriate data types - e.g. DECIMAL(15,4) for numbers, MONEY for money.

Jeremiah Peschka
I like the idea of "conveying meaning" instead of "getting the most digits out of my storage bytes".
Stephan Keller
To a point: I've had this backfire on me before when using the a higher scale would have avoided refactoring, despite the correct analysis and requirements
gbn