September 4, 2013 at 11:07 am
Show a series of start and stop times, listed for a group of people. calculate the elapsed times (or dates) and order them.
create table Runners
( runnerid int
, timemark time
)
insert runners (runnerid, timemark)
values (1, '12:00')
, (2, '12:00')
, (3, '12:00')
, (4, '12:00')
, (1, '12:15')
, (2, '12:17')
, (3, '12:16')
, (4, '12:15')
September 4, 2013 at 6:30 pm
Will each runner have at most 2 entries?
If only one entry (start time), then what would you like to see for elapsed time?
If more than 2, does the latest time count as the end time?
And what if it's a marathon that starts at 23:00 and runs over to the next day?
My thought question: Have you ever been told that your query runs too fast?
My advice:
INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?
The path of least resistance can be a slippery slope. Take care that fixing your fixes of fixes doesn't snowball and end up costing you more than fixing the root cause would have in the first place.
Need to UNPIVOT? Why not CROSS APPLY VALUES instead?[/url]
Since random numbers are too important to be left to chance, let's generate some![/url]
Learn to understand recursive CTEs by example.[/url]
[url url=http://www.sqlservercentral.com/articles/St
September 4, 2013 at 6:38 pm
Feel free to handle this as a couple pieces, perhaps in different ways.
For the first, let's say two times for each runner, could cross days.
If you want to tackle a second, make it more open ended. allow for errors, or assume there are splits and the last time is the end time.
September 4, 2013 at 7:07 pm
I'll give it a look this weekend.
My thought question: Have you ever been told that your query runs too fast?
My advice:
INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?
The path of least resistance can be a slippery slope. Take care that fixing your fixes of fixes doesn't snowball and end up costing you more than fixing the root cause would have in the first place.
Need to UNPIVOT? Why not CROSS APPLY VALUES instead?[/url]
Since random numbers are too important to be left to chance, let's generate some![/url]
Learn to understand recursive CTEs by example.[/url]
[url url=http://www.sqlservercentral.com/articles/St
September 4, 2013 at 7:21 pm
Thanks, and let me know.
September 6, 2013 at 8:32 pm
I've made a submission.
I hope it's what you were looking for and more importantly I hope I didn't miss some kind of trick part of the question.
My thought question: Have you ever been told that your query runs too fast?
My advice:
INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?
The path of least resistance can be a slippery slope. Take care that fixing your fixes of fixes doesn't snowball and end up costing you more than fixing the root cause would have in the first place.
Need to UNPIVOT? Why not CROSS APPLY VALUES instead?[/url]
Since random numbers are too important to be left to chance, let's generate some![/url]
Learn to understand recursive CTEs by example.[/url]
[url url=http://www.sqlservercentral.com/articles/St
September 10, 2013 at 6:38 pm
Interesting that this related thread should appear just now:
http://www.sqlservercentral.com/Forums/Topic1492737-3077-1.aspx?Update=1
My thought question: Have you ever been told that your query runs too fast?
My advice:
INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?
The path of least resistance can be a slippery slope. Take care that fixing your fixes of fixes doesn't snowball and end up costing you more than fixing the root cause would have in the first place.
Need to UNPIVOT? Why not CROSS APPLY VALUES instead?[/url]
Since random numbers are too important to be left to chance, let's generate some![/url]
Learn to understand recursive CTEs by example.[/url]
[url url=http://www.sqlservercentral.com/articles/St
September 16, 2013 at 7:44 am
Thanks, I'll look it over this week.
September 16, 2013 at 6:52 pm
I see you accepted it now for publication. That's cool!
I noticed that I misspelled "Spackle" as "Spacklet" in the title. I hope you can correct that before publication.
I don't want to mess with it myself now that it's been accepted (don't know what would happen to the status).
My thought question: Have you ever been told that your query runs too fast?
My advice:
INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?
The path of least resistance can be a slippery slope. Take care that fixing your fixes of fixes doesn't snowball and end up costing you more than fixing the root cause would have in the first place.
Need to UNPIVOT? Why not CROSS APPLY VALUES instead?[/url]
Since random numbers are too important to be left to chance, let's generate some![/url]
Learn to understand recursive CTEs by example.[/url]
[url url=http://www.sqlservercentral.com/articles/St
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply