InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comFri, 17 May 2013 23:26:50 GMT20http://www.sqlservercentral.com/Forums/Topic1154736-1495-1.aspxvery simple question but i got wrong answer.... little confusionMon, 28 Jan 2013 04:23:03 GMTmanik123http://www.sqlservercentral.com/Forums/Topic1154736-1495-1.aspxbit tricky:)Thu, 24 Jan 2013 21:04:26 GMTkalyani.k478http://www.sqlservercentral.com/Forums/Topic1154736-1495-1.aspx[quote][b]harsh.lapashiya (11/15/2011)[/b][hr]good twisterTo get third highest salaryselect MAX(salary) from Employees where salary <(select MAX(salary) from Employeeswhere salary <(select MAX(salary) from Employees))[/quote]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?Sun, 22 Jul 2012 15:57:19 GMTcodebyohttp://www.sqlservercentral.com/Forums/Topic1154736-1495-1.aspxThank you All!Sun, 22 Jul 2012 00:07:57 GMTVM-723206http://www.sqlservercentral.com/Forums/Topic1154736-1495-1.aspxGood Question. Thanks:-)Wed, 13 Jun 2012 08:08:23 GMTvinaybh1985http://www.sqlservercentral.com/Forums/Topic1154736-1495-1.aspxgood twisterTo get third highest salaryselect MAX(salary) from Employees where salary <(select MAX(salary) from Employeeswhere salary <(select MAX(salary) from Employees))Tue, 15 Nov 2011 07:45:55 GMTharsh.lapashiyahttp://www.sqlservercentral.com/Forums/Topic1154736-1495-1.aspxtricky question :-)Tue, 09 Aug 2011 13:42:09 GMTBuntyBoyhttp://www.sqlservercentral.com/Forums/Topic1154736-1495-1.aspxExcellent Question.... nice puzzling logic....Tue, 09 Aug 2011 04:08:55 GMTDhruvesh Shahhttp://www.sqlservercentral.com/Forums/Topic1154736-1495-1.aspxLove logic questions. Thanks!Mon, 08 Aug 2011 10:03:51 GMTKWymorehttp://www.sqlservercentral.com/Forums/Topic1154736-1495-1.aspx[quote][b]Tom.Thomson (8/7/2011)[/b][hr][quote][b]john.arnott (8/6/2011)[/b][hr]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, ....[/quote]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.[/quote]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.Sun, 07 Aug 2011 22:03:40 GMTjohn.arnotthttp://www.sqlservercentral.com/Forums/Topic1154736-1495-1.aspxEasy 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. :)Sun, 07 Aug 2011 17:26:54 GMTcodebyohttp://www.sqlservercentral.com/Forums/Topic1154736-1495-1.aspx[quote][b]john.arnott (8/6/2011)[/b][hr]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, ....[/quote]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.Sun, 07 Aug 2011 08:45:06 GMTL' Eomot Inverséhttp://www.sqlservercentral.com/Forums/Topic1154736-1495-1.aspxHi 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 [i]extremely[/i] 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 :-PThe excellent point Tom made is that floating-point numbers are an [i]exact[/i] 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 :-)Sat, 06 Aug 2011 23:40:04 GMTPaul Whitehttp://www.sqlservercentral.com/Forums/Topic1154736-1495-1.aspxPerhaps 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 [url=http://msdn.microsoft.com/en-us/library/ms187912.aspx][b]Microsoft's recommendation on use of Float or Real [/b][/url].[quote]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. [/quote]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.Sat, 06 Aug 2011 20:25:19 GMTjohn.arnotthttp://www.sqlservercentral.com/Forums/Topic1154736-1495-1.aspxGood one!!! Thanks for the question.Sat, 06 Aug 2011 17:11:10 GMTAbi Chapagaihttp://www.sqlservercentral.com/Forums/Topic1154736-1495-1.aspx[quote][b]Cliff Jones (8/6/2011)[/b][hr][quote][b]SQLkiwi (8/5/2011)[/b][hr][quote][b]Tom.Thomson (8/5/2011)[/b][hr]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.[/quote]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[sup]53[/sup] / 100.[/quote]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?[/quote]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.Sat, 06 Aug 2011 12:41:59 GMTL' Eomot Inverséhttp://www.sqlservercentral.com/Forums/Topic1154736-1495-1.aspxI 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.Sat, 06 Aug 2011 11:23:57 GMTjlennartzhttp://www.sqlservercentral.com/Forums/Topic1154736-1495-1.aspx[quote][b]SQLkiwi (8/5/2011)[/b][hr][quote][b]Tom.Thomson (8/5/2011)[/b][hr]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.[/quote]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[sup]53[/sup] / 100.[/quote]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?Sat, 06 Aug 2011 07:18:11 GMTCliff Joneshttp://www.sqlservercentral.com/Forums/Topic1154736-1495-1.aspx[quote][b]Tom.Thomson (8/5/2011)[/b][hr]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.[/quote]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[sup]53[/sup] / 100.Fri, 05 Aug 2011 21:18:05 GMTPaul Whitehttp://www.sqlservercentral.com/Forums/Topic1154736-1495-1.aspx[quote][b]Dave62 (8/5/2011)[/b][hr]For those who were expecting the third highest salary, here is a select for that [...][/quote]Or, slightly more compactly:[code="sql"]select max(Salary) from @table where Salary <((select max(Salary) from @table where Salary < (select max(Salary) from @table)))[/code]Fri, 05 Aug 2011 21:00:39 GMTPaul Whitehttp://www.sqlservercentral.com/Forums/Topic1154736-1495-1.aspxYou almost had me :laugh:Fri, 05 Aug 2011 20:51:59 GMTPaul Whitehttp://www.sqlservercentral.com/Forums/Topic1154736-1495-1.aspxGreat Question. Saw that your NOT IN had only one result and NOT ;-) two right away.Fri, 05 Aug 2011 14:14:16 GMTSanDroidhttp://www.sqlservercentral.com/Forums/Topic1154736-1495-1.aspx[quote][b]Tom.Thomson (8/5/2011)[/b][hr][quote][b]john.arnott (8/5/2011)[/b][hr][quote][b]Cliff Jones (8/5/2011)[/b][hr]I thought this question was about using approximate data types so got it right for the wrong reason.[/quote]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.[/quote]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.[/quote]Nice one TOM... FLOATing is better than SINking... :cool: :hehe:"Life is tough, it's tougher if your are stupid and use COBOL" -RGB develeopment team mottoFri, 05 Aug 2011 14:12:42 GMTSanDroidhttp://www.sqlservercentral.com/Forums/Topic1154736-1495-1.aspx[quote][b]john.arnott (8/5/2011)[/b][hr][quote][b]Cliff Jones (8/5/2011)[/b][hr]I thought this question was about using approximate data types so got it right for the wrong reason.[/quote]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.[/quote]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.Fri, 05 Aug 2011 11:53:20 GMTL' Eomot Inverséhttp://www.sqlservercentral.com/Forums/Topic1154736-1495-1.aspxThis 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.Fri, 05 Aug 2011 11:39:40 GMTRose Budhttp://www.sqlservercentral.com/Forums/Topic1154736-1495-1.aspx[quote][b]Cliff Jones (8/5/2011)[/b][hr]I thought this question was about using approximate data types so got it right for the wrong reason.[/quote]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.Fri, 05 Aug 2011 10:51:06 GMTjohn.arnotthttp://www.sqlservercentral.com/Forums/Topic1154736-1495-1.aspxExcellent question and indeed a brain teaser!Fri, 05 Aug 2011 10:47:51 GMTAmolNaikhttp://www.sqlservercentral.com/Forums/Topic1154736-1495-1.aspxI thought this question was about using approximate data types so got it right for the wrong reason.Fri, 05 Aug 2011 10:29:02 GMTCliff Joneshttp://www.sqlservercentral.com/Forums/Topic1154736-1495-1.aspxthanks for the ¿Fri, 05 Aug 2011 10:23:34 GMTSQLRNNRhttp://www.sqlservercentral.com/Forums/Topic1154736-1495-1.aspxGreat question! ThanksFri, 05 Aug 2011 10:14:09 GMTRafael Krisllerhttp://www.sqlservercentral.com/Forums/Topic1154736-1495-1.aspx[quote][b]Sean Lange (8/5/2011)[/b][hr][quote][b]BenWard (8/5/2011)[/b][hr]Am I the only person who thinks those salaries are horrifically low?! If I was only paid 5000 units of currency per year (regardless of currency!) I wouldn't be best pleased! :Dagain, nice question.[/quote]I just assumed those were hourly, much like mine. :-P[/quote]Or match appearance fees!Thanks for the question btw...Fri, 05 Aug 2011 09:52:16 GMTOzYbOi d(-_-)bhttp://www.sqlservercentral.com/Forums/Topic1154736-1495-1.aspx[quote][b]Sean Lange (8/5/2011)[/b][hr][quote][b]BenWard (8/5/2011)[/b][hr]Am I the only person who thinks those salaries are horrifically low?! If I was only paid 5000 units of currency per year (regardless of currency!) I wouldn't be best pleased! :Dagain, nice question.[/quote]I just assumed those were hourly, much like mine. :-P[/quote]lots of rupees for you! :-DFri, 05 Aug 2011 08:59:25 GMTBenWardhttp://www.sqlservercentral.com/Forums/Topic1154736-1495-1.aspx[quote][b]BenWard (8/5/2011)[/b][hr]Am I the only person who thinks those salaries are horrifically low?! If I was only paid 5000 units of currency per year (regardless of currency!) I wouldn't be best pleased! :Dagain, nice question.[/quote]I just assumed those were hourly, much like mine. :-PFri, 05 Aug 2011 08:54:58 GMTSean Langehttp://www.sqlservercentral.com/Forums/Topic1154736-1495-1.aspxAm I the only person who thinks those salaries are horrifically low?! If I was only paid 5000 units of currency per year (regardless of currency!) I wouldn't be best pleased! :Dagain, nice question.Fri, 05 Aug 2011 08:18:02 GMTBenWardhttp://www.sqlservercentral.com/Forums/Topic1154736-1495-1.aspxFor those who were expecting the third highest salary, here is a select for that[code="sql"]declare @table table(ID int identity(1,1) not null, Name varchar(10), Salary float)insert into @table values ('A',123.45)insert into @table values ('B',543.44)insert into @table values ('C',654.44)insert into @table values ('D',848.93)insert into @table values ('C',2372.46)insert into @table values ('D',4775.44)insert into @table values ('E',5676.45)insert into @table values ('F',244.44)insert into @table values ('G',3434.44)insert into @table values ('H',666.93)insert into @table values ('I',444.46)insert into @table values ('J',123.44)select max(Salary) from @table where Salary not in ( select max(Salary) from @table where Salary not in ( select max(Salary) from @table ) )-- This returns the third highest salarySelect MAX(t2.Salary) As "Salary" From (Select Salary From @table Where Salary Not In (Select MAX(Salary) From @table)) As "t2" Where t2.Salary Not In ( -- This returns the second highest salary Select MAX(t1.Salary) As "Salary" From (Select Salary From @table Where Salary Not In ( -- This returns the highest salary Select MAX(Salary) From @table )) As "t1" );[/code]Enjoy!DaveFri, 05 Aug 2011 08:10:01 GMTDave62http://www.sqlservercentral.com/Forums/Topic1154736-1495-1.aspxThis may be a trick question, but it is a GOOD trick question. This is actually the sort of thing that happens in the real world with inexperienced developers, or when people have gone without sleep for too long and are still working. Good to train that sort of thinking.Fri, 05 Aug 2011 07:59:00 GMTjeff.masonhttp://www.sqlservercentral.com/Forums/Topic1154736-1495-1.aspxBest question for ages!Nice one VM!Fri, 05 Aug 2011 07:51:46 GMTpaul s-306273http://www.sqlservercentral.com/Forums/Topic1154736-1495-1.aspxGot me tricked. Nice question. Thanks!Fri, 05 Aug 2011 07:49:20 GMTmapledanishhttp://www.sqlservercentral.com/Forums/Topic1154736-1495-1.aspxThat was an excellent question, and not at all a "trick question"... very nice!ronFri, 05 Aug 2011 07:41:50 GMTronmoseshttp://www.sqlservercentral.com/Forums/Topic1154736-1495-1.aspxThanks for the question. Glad it combined T-SQL with some logic. Not all questions have to have something to do with unexpected behavior/"features" of SQL Server. Once you know those things, you still have to apply that information logically to solve a problem. Important to know if the problem you solve is the problem you meant to solve.Fri, 05 Aug 2011 07:38:18 GMTThomas Abraham