August 6, 2011 at 5:11 pm
Good one!!! Thanks for the question.
August 6, 2011 at 8:25 pm
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.
August 6, 2011 at 11:40 pm
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 🙂
Paul White
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi
August 7, 2011 at 8:45 am
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
August 7, 2011 at 5:26 pm
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
August 7, 2011 at 10:03 pm
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.
August 8, 2011 at 10:03 am
Love logic questions. Thanks!
August 9, 2011 at 4:08 am
Excellent Question.... nice puzzling logic....
August 9, 2011 at 1:42 pm
November 15, 2011 at 7:45 am
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))
June 13, 2012 at 8:08 am
Good Question. Thanks:-)
July 22, 2012 at 12:07 am
Thank you All!
July 22, 2012 at 3:57 pm
harsh.lapashiya (11/15/2011)
good twisterTo 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
January 24, 2013 at 9:04 pm
bit tricky:)
January 28, 2013 at 4:23 am
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 59 (of 59 total)
You must be logged in to reply to this topic. Login to reply