Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase «««23456»»

How well do you know MAX? Expand / Collapse
Author
Message
Posted Friday, August 5, 2011 9:00 PM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: 2 days ago @ 4:20 PM
Points: 11,194, Visits: 11,142
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
Post #1155474
Posted Friday, August 5, 2011 9:18 PM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: 2 days ago @ 4:20 PM
Points: 11,194, Visits: 11,142
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 253 / 100.




Paul White
SQL Server MVP
SQLblog.com
@SQL_Kiwi
Post #1155476
Posted Saturday, August 6, 2011 7:18 AM
Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Friday, August 29, 2014 8:18 AM
Points: 3,909, Visits: 3,636
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 253 / 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?
Post #1155538
Posted Saturday, August 6, 2011 11:23 AM
Right there with Babe

Right there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with Babe

Group: General Forum Members
Last Login: Wednesday, August 27, 2014 3:43 PM
Points: 773, Visits: 1,172
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.
Post #1155567
Posted Saturday, August 6, 2011 12:41 PM


SSCrazy Eights

SSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy Eights

Group: General Forum Members
Last Login: Today @ 8:48 AM
Points: 8,739, Visits: 9,287
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 253 / 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
Post #1155578
Posted Saturday, August 6, 2011 5:11 PM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Saturday, August 23, 2014 8:06 AM
Points: 1,786, Visits: 1,113
Good one!!! Thanks for the question.
Post #1155613
Posted Saturday, August 6, 2011 8:25 PM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Thursday, August 28, 2014 8:53 PM
Points: 1,521, Visits: 3,039
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.
Post #1155625
Posted Saturday, August 6, 2011 11:40 PM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: 2 days ago @ 4:20 PM
Points: 11,194, Visits: 11,142
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
SQL Server MVP
SQLblog.com
@SQL_Kiwi
Post #1155631
Posted Sunday, August 7, 2011 8:45 AM


SSCrazy Eights

SSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy Eights

Group: General Forum Members
Last Login: Today @ 8:48 AM
Points: 8,739, Visits: 9,287
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
Post #1155671
Posted Sunday, August 7, 2011 5:26 PM


SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Thursday, August 21, 2014 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
Post #1155741
« Prev Topic | Next Topic »

Add to briefcase «««23456»»

Permissions Expand / Collapse