August 10, 2018 at 2:43 pm
Sean Lange - Friday, August 10, 2018 7:17 AMBeatrix Kiddo - Friday, August 10, 2018 6:20 AMShouldn't they be banned or something? (Edit: too slow.)There needs to be an option for "rude/offensive" in the flag reasons. I have seen some people lose their minds on the forums but that is a whole new level.
And seriously Jeff...you need to start helping people instead of just trolling. 😀
😀
--Jeff Moden
Change is inevitable... Change for the better is not.
August 10, 2018 at 2:44 pm
Thom A - Friday, August 10, 2018 2:40 PMDon't mind me, just blowing off steam here.This is on a different site, but it really annoys me when someone tells me that "this method" is better than mine, because theirs doesn't have the problem mine does, when in fact, it does. Not only that, but when you try to educate them on why, they refuse to believe it.
Had someone telling me that a CURSOR was an awful solution for something (without going into detail, it's not as it's repeating on objects not rows), however, that a self referencing variable isn't RBAR, and far better. A self referencing variable is RBAR. ARGH!!!!
/Rant over.
Thom, this rant is incorrectly formed: there is no /rant start tag 🙂
The absence of evidence is not evidence of absence
- Martin Rees
The absence of consumable DDL, sample data and desired results is, however, evidence of the absence of my response
- Phil Parkin
August 10, 2018 at 2:46 pm
Thom A - Friday, August 10, 2018 2:40 PMDon't mind me, just blowing off steam here.This is on a different site, but it really annoys me when someone tells me that "this method" is better than mine, because theirs doesn't have the problem mine does, when in fact, it does. Not only that, but when you try to educate them on why, they refuse to believe it.
Had someone telling me that a CURSOR was an awful solution for something (without going into detail, it's not as it's repeating on objects not rows), however, that a self referencing variable isn't RBAR, and far better. A self referencing variable is RBAR. ARGH!!!!
/Rant over.
At least for entertainment purposes, I'd love to see that thread. Got a link that you don't mind sharing?
--Jeff Moden
Change is inevitable... Change for the better is not.
August 10, 2018 at 3:26 pm
[/quote]
I'm not a massive fan on the community on the site, so I use a psuedonym on it. Would give the game away I'm afraid! Sorry 🙂
I wish there was an option to view the source code for posts, I have no idea why that quotebox looks awful (and has [/quote] at the end) in the post, but in the preview it's fine.
Thom~
Excuse my typos and sometimes awful grammar. My fingers work faster than my brain does.
Larnu.uk
August 10, 2018 at 6:34 pm
Thom A - Friday, August 10, 2018 2:40 PMDon't mind me, just blowing off steam here.This is on a different site, but it really annoys me when someone tells me that "this or that method" is better than mine, because their/that method doesn't have the problem mine does, when in fact, it does. Not only that, but when you try to educate them on why, they refuse to believe it.
Had someone telling me that a CURSOR was an awful solution for something (without going into detail, it's not as it's repeating on objects not rows), however, that a self referencing variable isn't RBAR, and far better. A self referencing variable is RBAR. ARGH!!!!
/Rant over.
Hmm, you know, it's actually better.
And it's not exactly RBAR.
Unless we have different understanding of self-referencing variables.
Simple code to prove the point:set statistics IO, time off
GO
declare @Time datetime
set @Time = GETDATE()
declare @NumberOfNullableColumns int, @NullableColumn int
declare NullableColumn cursor for
SELECT [is_nullable]
FROM [master].[sys].[all_columns]
open NullableColumn
fetch next from NullableColumn into @NullableColumn
while @@FETCH_STATUS = 0
begin
SET @NumberOfNullableColumns = ISNULL(@NumberOfNullableColumns, 0) + @NullableColumn
fetch next from NullableColumn into @NullableColumn
end
close NullableColumn
deallocate NullableColumn
select @NumberOfNullableColumns [@NumberOfNullableColumns]
set @Time = GETDATE() - @Time
print convert(varchar(30), @Time, 121)
GO
declare @Time datetime
set @Time = GETDATE()
declare @NumberOfNullableColumns int
SELECT @NumberOfNullableColumns = ISNULL(@NumberOfNullableColumns, 0) + [is_nullable]
FROM [master].[sys].[all_columns]
select @NumberOfNullableColumns [@NumberOfNullableColumns]
set @Time = GETDATE() - @Time
print convert(varchar(30), @Time, 121)
GO
If you try to catch statistics (or execution plans) you'll see bunch of "1 row affected" in case of the CURSOR, and single "NNNN rows affected" with the variable approach.
So, I guess, you're letting your steam out the wrong way. 🙂
_____________
Code for TallyGenerator
August 10, 2018 at 8:00 pm
Thom A - Friday, August 10, 2018 3:26 PMJeff Moden - Friday, August 10, 2018 2:46 PMAt least for entertainment purposes, I'd love to see that thread. Got a link that you don't mind sharing?
I'm not a massive fan on the community on the site, so I use a psuedonym on it. Would give the game away I'm afraid! Sorry 🙂
[/quote]
Don't forget that the Quirky Update uses a couple of "self referencing" variables and it doesn't fall into the definition of "RBAR".
--Jeff Moden
Change is inevitable... Change for the better is not.
August 11, 2018 at 4:37 am
Jeff Moden - Friday, August 10, 2018 8:00 PMDon't forget that the Quirky Update uses a couple of "self referencing" variables and it doesn't fall into the definition of "RBAR".
This was more for creating a string (not delimited, but same idea). I thought that that method was a hidden RBAR. Using FOR XML PATH and STUFF hugely out performs something like SELECT @Variable = (',' + @Variable,'') + @Variable FROM YourTable, and I was under the impression that the main reason is because SQl Server does actually produce the string in an RBAR method.
Thom~
Excuse my typos and sometimes awful grammar. My fingers work faster than my brain does.
Larnu.uk
August 11, 2018 at 4:49 am
Thom A - Saturday, August 11, 2018 4:37 AMThis was more for creating a string (not delimited, but same idea). I thought that that method was a hidden RBAR. Using FOR XML PATH and STUFF hugely out performs something like SELECT @Variable = (',' + @Variable,'') + @Variable FROM YourTable, and I was under the impression that the main reason is because SQl Server does actually produce the string in an RBAR method.
Have you tested this Tom?
😎
I've (in the passed, not tested this recently) found that SELECT @VAR = @VAR + [COLUMN_NAME] generally performs faster because of the XML overhead. The only reason for using the FOR XML method, is because that is the only way of guaranteeing the order of the elements.
August 11, 2018 at 4:57 am
Thom A - Saturday, August 11, 2018 4:37 AMThis was more for creating a string (not delimited, but same idea). I thought that that method was a hidden RBAR. Using FOR XML PATH and STUFF hugely out performs something like SELECT @Variable = (',' + @Variable,'') + @Variable FROM YourTable, and I was under the impression that the main reason is because SQl Server does actually produce the string in an RBAR method.
That method does work set-based (obviously at the execution plan level it is still RBAR, but that goes for each and every single query you ever execute). It performs a bit slower than normal set-based code, but lots faster than actual iterative code.
However, the real problem with this query pattern is that the language definition does not specify what the correct result should be. (And in fact, the result most people expect is actually the least expected based on strict interpretation of the documentation). For example, look at the code below, predict what it will return, then run it.USE AdventureWorks2017;
GO
DECLARE @v-2 varchar(MAX) = '';
SELECT @v-2 = ', ' + d.Name + @v-2
FROM HumanResources.Department AS d;
SELECT STUFF(@v, 1, 2, '');
GO
DECLARE @v-2 varchar(MAX) = '';
SELECT @v = ', ' + d.Name + @v-2
FROM HumanResources.Department AS d
ORDER BY LEN(d.GroupName);
SELECT STUFF(@v, 1, 2, '');
GO
August 11, 2018 at 5:49 am
Eirikur Eiriksson - Saturday, August 11, 2018 4:49 AMHave you tested this Tom?
😎
I've (in the passed, not tested this recently) found that SELECT @VAR = @VAR + [COLUMN_NAME] generally performs faster because of the XML overhead. The only reason for using the FOR XML method, is because that is the only way of guaranteeing the order of the elements.
Yes, that is something I made sure of before so. As things scaled, the self referencing variable performance really wasn't anywhere near close to FOR XML PATH. This was on my home environment though, but still, I wouldn't expect such a massive difference between the 2.
Thom~
Excuse my typos and sometimes awful grammar. My fingers work faster than my brain does.
Larnu.uk
August 11, 2018 at 6:25 am
Thom A - Saturday, August 11, 2018 5:49 AMYes, that is something I made sure of before so. As things scaled, the self referencing variable performance really wasn't anywhere near close to FOR XML PATH. This was on my home environment though, but still, I wouldn't expect such a massive difference between the 2.
If one can avoid reconstructing the XML for the output, the FOR XML PATH has only the penalty of a single XML operator, otherwise it gets quite expensive. I'll have to look into my notes but if I remember correctly, I wasn't doing very high cardinality in my tests, only few tens of thousands.
😎
August 11, 2018 at 1:08 pm
Thom A - Saturday, August 11, 2018 4:37 AMThis was more for creating a string (not delimited, but same idea). I thought that that method was a hidden RBAR. Using FOR XML PATH and STUFF hugely out performs something like SELECT @Variable = (',' + @Variable,'') + @Variable FROM YourTable, and I was under the impression that the main reason is because SQl Server does actually produce the string in an RBAR method.
Ahhh... Understood. Yes, it's a form of hidden RBAR but has few replacements. I actually wrote an article on it a very long time ago. The XML method tested out to be about 30% slower than the obvious RBAR method (including a scalar function) way, way back (IIRC, I was still on a 32 bit machine). I've not retested it since then.
Here's the link.
http://www.sqlservercentral.com/articles/Test+Data/61572/
The only reason (back then) to use the XML method is because so many people are outraged by the use of scalar functions as well as the outrage about not being able to control the variable overlay (which you can, indeed!) or because you can't actually create the right kind of index to support the RBAR method.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 11, 2018 at 1:09 pm
Thom A - Saturday, August 11, 2018 5:49 AMYes, that is something I made sure of before so. As things scaled, the self referencing variable performance really wasn't anywhere near close to FOR XML PATH. This was on my home environment though, but still, I wouldn't expect such a massive difference between the 2.
It's all in the indexes, like the article says. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
August 12, 2018 at 9:40 am
Jeff Moden - Saturday, August 11, 2018 1:09 PMIt's all in the indexes, like the article says. 😉
You mean "indices"
😎
August 13, 2018 at 3:26 am
Hmm, I would use indices in a financial markets context, but indexes in a database context.
Viewing 15 posts - 61,966 through 61,980 (of 66,712 total)
You must be logged in to reply to this topic. Login to reply