August 5, 2011 at 10:14 am
Great question!
Thanks
August 5, 2011 at 10:23 am
thanks for the ¿
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
August 5, 2011 at 10:29 am
I thought this question was about using approximate data types so got it right for the wrong reason.
August 5, 2011 at 10:47 am
Excellent question and indeed a brain teaser!
Amol Naik
August 5, 2011 at 10:51 am
Cliff Jones (8/5/2011)
I thought this question was about using approximate data types so got it right for the wrong reason.
I would hope that most viewers of this understand that the FLOAT datatype is generally not a good idea for monetary values, but let's say it to be sure.
August 5, 2011 at 11:39 am
This has been one of the best weeks for QOTD that I can remember, and today's question was like the frosting on the cake! Thanks to all of you who put the effort into submitting questions to educate and amuse us.
August 5, 2011 at 11:53 am
john.arnott (8/5/2011)
Cliff Jones (8/5/2011)
I thought this question was about using approximate data types so got it right for the wrong reason.I would hope that most viewers of this understand that the FLOAT datatype is generally not a good idea for monetary values, but let's say it to be sure.
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.
But. let's say it, just to be sure that the anti-float myth invented years ago by Cobol advocates is not carried over unchallenged into modern times.
Tom
August 5, 2011 at 2:12 pm
Tom.Thomson (8/5/2011)
john.arnott (8/5/2011)
Cliff Jones (8/5/2011)
I thought this question was about using approximate data types so got it right for the wrong reason.I would hope that most viewers of this understand that the FLOAT datatype is generally not a good idea for monetary values, but let's say it to be sure.
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.
But. let's say it, just to be sure that the anti-float myth invented years ago by Cobol advocates is not carried over unchallenged into modern times.
Nice one TOM... FLOATing is better than SINking... 😎 :hehe:
"Life is tough, it's tougher if your are stupid and use COBOL"
-RGB develeopment team motto
August 5, 2011 at 2:14 pm
Great Question. Saw that your NOT IN had only one result and NOT 😉 two right away.
August 5, 2011 at 8:51 pm
You almost had me :laugh:
Paul White
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi
August 5, 2011 at 9:00 pm
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
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi
August 5, 2011 at 9:18 pm
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
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi
August 6, 2011 at 7:18 am
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?
August 6, 2011 at 11:23 am
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.
August 6, 2011 at 12:41 pm
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
Viewing 15 posts - 31 through 45 (of 59 total)
You must be logged in to reply to this topic. Login to reply