

SSChampion
Group: General Forum Members
Last Login: Yesterday @ 10:26 AM
Points: 11,194,
Visits: 11,136


Dave62 (8/5/2011) For those who were expecting the third highest salary, here is a select for that [...] Or, slightly more compactly:
select max(Salary) from @table where Salary < ((select max(Salary) from @table where Salary < (select max(Salary) from @table)))
Paul White SQL Server MVP SQLblog.com @SQL_Kiwi




SSChampion
Group: General Forum Members
Last Login: Yesterday @ 10:26 AM
Points: 11,194,
Visits: 11,136


Tom.Thomson (8/5/2011) I would hope that most people realise that in applications where monetary values range from 0.01 units to 90071992547409.92 units (something over nine hundred million million units), and no greater accuracy than two places after the point is needed, float (which is a synonym for float(53)) is usually far more storage efficient and usually far mor eperformance efficient than any decimal or money type, and no less accurate. Let's hope people also realise that that covers the vast majority of applications involving monetary values. Excellent point! FLOAT is used extensively at the financial institution I am currently engaged at for precisely (ha!) these reasons, especially performance. For anyone wondering, 90071992547409.92 is 2^{53} / 100.
Paul White SQL Server MVP SQLblog.com @SQL_Kiwi




Hall of Fame
Group: General Forum Members
Last Login: Yesterday @ 11:27 PM
Points: 3,901,
Visits: 3,634


SQLkiwi (8/5/2011)
Tom.Thomson (8/5/2011) I would hope that most people realise that in applications where monetary values range from 0.01 units to 90071992547409.92 units (something over nine hundred million million units), and no greater accuracy than two places after the point is needed, float (which is a synonym for float(53)) is usually far more storage efficient and usually far mor eperformance efficient than any decimal or money type, and no less accurate. Let's hope people also realise that that covers the vast majority of applications involving monetary values.Excellent point! FLOAT is used extensively at the financial institution I am currently engaged at for precisely (ha!) these reasons, especially performance. For anyone wondering, 90071992547409.92 is 2 ^{53} / 100. I agree, I learned something. I don't deal much with financial data but thought that it was a mistake to use approximate data types for money. Don't you have difficulty with being slightly off when performing calculations?
Wasn't that how Lex Luther got rich?




Right there with Babe
Group: General Forum Members
Last Login: 2 days ago @ 1:26 PM
Points: 773,
Visits: 1,168


I would say that this question should definitely be considered a trick question because the title asks how well you know Max where in reality it was how well you knew what subquery's would return. Max did exactly what I thought it should it returned the max from the values passed to it. The fact that the highest value was still in the mix for the last select tripped me up.




SSCrazy Eights
Group: General Forum Members
Last Login: Today @ 11:01 AM
Points: 8,684,
Visits: 9,212


Cliff Jones (8/6/2011)
SQLkiwi (8/5/2011)
Tom.Thomson (8/5/2011) I would hope that most people realise that in applications where monetary values range from 0.01 units to 90071992547409.92 units (something over nine hundred million million units), and no greater accuracy than two places after the point is needed, float (which is a synonym for float(53)) is usually far more storage efficient and usually far mor eperformance efficient than any decimal or money type, and no less accurate. Let's hope people also realise that that covers the vast majority of applications involving monetary values.Excellent point! FLOAT is used extensively at the financial institution I am currently engaged at for precisely (ha!) these reasons, especially performance. For anyone wondering, 90071992547409.92 is 2 ^{53} / 100. I agree, I learned something. I don't deal much with financial data but thought that it was a mistake to use approximate data types for money. Don't you have difficulty with being slightly off when performing calculations? If you count cents (so that 1 dollar is represented by the number 100, not by 1) float gives exact representation for all multiples of 1 cent between $90071992547409.92 and $90071992547409.92 inclusive, so you won't be any more off when performing calculations than you would have been with numeric(16,2). Your storage is 8 bytes per number instead of 9. If you represent a dollar by the number 1 you may have some problems. I know that some financial institutions are perfectly happy to live with those problems  maybe others are not.
Of course you may have difficulties in some areas because the float calculations don't produce fixed rounding errors as rapidly as the numeric(16,2) ones  maybe you want (sum (x/3)) to be different from sum(x)/3 because the rules for the caculation require committing the rounding error caused by sticking to the fixed accuracy at each individual division or multiplication. So maybe bigint would be a better representation than float if most of your calculations are like that. But of course you can always commit the rounding errors by casting out and back when you want to fix them, and maybe only some of your calculations require it.
Tom




SSCommitted
Group: General Forum Members
Last Login: Tuesday, August 5, 2014 5:41 PM
Points: 1,786,
Visits: 1,112


Good one!!! Thanks for the question.




SSCommitted
Group: General Forum Members
Last Login: Sunday, April 27, 2014 6:26 AM
Points: 1,521,
Visits: 3,036


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.




SSChampion
Group: General Forum Members
Last Login: Yesterday @ 10:26 AM
Points: 11,194,
Visits: 11,136


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 floatingpoint arithmetic if it gave us wrong answers
The excellent point Tom made is that floatingpoint 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 monetaryvalue application? It depends, of course
Paul White SQL Server MVP SQLblog.com @SQL_Kiwi




SSCrazy Eights
Group: General Forum Members
Last Login: Today @ 11:01 AM
Points: 8,684,
Visits: 9,212


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




SSC Eights!
Group: General Forum Members
Last Login: Today @ 5:59 AM
Points: 897,
Visits: 1,488


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



