# How well do you know MAX?

• Good one!!! Thanks for the question.

• Perhaps put off by the apparent snarkiness ("I would hope that most...") of Tom's refutal of my post questioning the use of Float for monetary values, I decided to let it go. Now that MVP Paul has chimed in on the side of Float for financial data, I wonder whether there's a good, simple explanation of when to put aside Microsoft's recommendation on use of Float or Real .

Approximate numeric data types do not store the exact values specified for many numbers; they store an extremely close approximation of the value. For many applications, the tiny difference between the specified value and the stored approximation is not noticeable. At times, though, the difference becomes noticeable. Because of the approximate nature of the float and real data types, do not use these data types when exact numeric behavior is required, such as in financial applications, in operations involving rounding, or in equality checks. Instead, use the integer, decimal, money, or smallmoney data types.

Seems to me that if you can't guarantee future uses of data (vis a vis rounding and so on) that you'd be taking a risk trying to save a byte per datum by using float.

• Hi John,

I think you may have missed the humour in Tom's reply to you, but never mind.

There's nothing incompatible between that general BOL advice and what's been said so far. The key phrases are things like "for many applications" and "where exact numeric behaviour is required". In many financial applications (the client I was referring to uses MATLAB) double precision arithmetic is preferred because this hedge fund is looking for trends and shapes over time, in extremely large data sets.

The alternative internal format for our needs would be DECIMAL(38,20), which requires 17 bytes compared with 8. More importantly, processing hundreds of billions of records is at least an order of magnitude slower than using float. Naturally, we would not use floating-point arithmetic if it gave us wrong answers 😛

The excellent point Tom made is that floating-point numbers are an exact representation for integers over a very large range, a point that is not well understood by most DBAs.

So, is it is better to use floating point or a limited precision 'exact' numeric in a given monetary-value application? It depends, of course 🙂

• john.arnott (8/6/2011)

Perhaps put off by the apparent snarkiness ("I would hope that most...") of Tom's refutal of my post questioning the use of Float for monetary values, ....

You must have missed that "I would hope that most" and "But let's say it" were echoes? I thought that such clear echoes eliminated the need for smileys. Evidently I was wrong. I'm sorry if I caused offence.

Edit: B****y English grammar.

Tom

• Easy question. You get it right by analyzing the innermost queries first and then understanding how the NOT IN operator works in the outermost query.

I love this kind of questions. Thank you. 🙂

Best regards,

Andre Guerreiro Neto

Database Analyst
http://www.softplan.com.br
MCITPx1/MCTSx2/MCSE/MCSA

• Tom.Thomson (8/7/2011)

john.arnott (8/6/2011)

Perhaps put off by the apparent snarkiness ("I would hope that most...") of Tom's refutal of my post questioning the use of Float for monetary values, ....

You must have missed that "I would hope that most" and "But let's say it" were echoes? I thought that such clear echoes eliminated the need for smileys. Evidently I was wrong. I'm sorry if I caused offence.

Edit: B****y English grammar.

Tom,

It was more than clear that you echoed my structure. It was obvious that you were attempting to be humorous, but I have to point out that any humor found would only have been at my expense. Smileys may or may not have helped. Sometimes it's easy to forget that although a rebuttal stated mockingly may be an effective rhetorical tool to reinforce one's point, it can be considered a personal affront. A deliberate echo of someone's writing that turns his words upon his own statement can seem to attack the writer of that post more than its content.

I do accept your apology and thank you for opening the dialog on a point that deserves attention, even if it's not so simple a topic as a COBOL-inspired myth that needs debunking. This may not be the appropriate thread in which to continue that discussion, but your point and Paul's clarifications have certainly been valuable to me.

• Love logic questions. Thanks!

• Excellent Question.... nice puzzling logic....

• tricky question 🙂

===========================================
Better try and fail than not to try at all...

Database Best Practices[/url]

SQL Server Best Practices[/url]

• good twister

To get third highest salary

select MAX(salary) from Employees where salary <(select MAX(salary) from Employees

where salary <(select MAX(salary) from Employees))

• Good Question. Thanks:-)

• Thank you All!

• harsh.lapashiya (11/15/2011)

good twister

To get third highest salary

select MAX(salary) from Employees where salary <(select MAX(salary) from Employees

where salary <(select MAX(salary) from Employees))

I know this is a year old post but I just wonder how the performance would be when you have a large Employees table. Is this the recommended method to do it?

Best regards,

Andre Guerreiro Neto

Database Analyst
http://www.softplan.com.br
MCITPx1/MCTSx2/MCSE/MCSA

• bit tricky:)

• very simple question but i got wrong answer.... little confusion

Manik
You cannot get to the top by sitting on your bottom.

Viewing 15 posts - 46 through 60 (of 60 total)