August 2, 2013 at 11:07 am
Lynn Pettis (7/31/2013)
FYI, Anyone considering Care Packages to Afghanistan, the first package from home took 9 days to get here.
we'll send you some fresh cream, and you can enjoy the cheese when you open it. 😀
---------------------------------------------------------
How best to post your question[/url]
How to post performance problems[/url]
Tally Table:What it is and how it replaces a loop[/url]
"stewsterl 80804 (10/16/2009)I guess when you stop and try to understand the solution provided you not only learn, but save yourself some headaches when you need to make any slight changes."
August 2, 2013 at 12:14 pm
jcrawf02 (8/2/2013)
Lynn Pettis (7/31/2013)
FYI, Anyone considering Care Packages to Afghanistan, the first package from home took 9 days to get here.we'll send you some fresh cream, and you can enjoy the cheese when you open it. 😀
We could send him a puppy, it'd be a nice friendly dog by the time it gets there...
:hehe:
August 2, 2013 at 4:55 pm
jasona.work (8/2/2013)
jcrawf02 (8/2/2013)
Lynn Pettis (7/31/2013)
FYI, Anyone considering Care Packages to Afghanistan, the first package from home took 9 days to get here.we'll send you some fresh cream, and you can enjoy the cheese when you open it. 😀
We could send him a puppy, it'd be a nice friendly dog by the time it gets there...
:hehe:
Which breed should we send?
Doberman?
Bulldog?
German Shepherd?
Pit Bull?
Poodle?
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 3, 2013 at 10:21 am
Brandie Tarvin (8/2/2013)
How many people (besides Jeff and myself) have written SQL Spackle articles?How many SQL Spackle articles are there?
Yes, I have a reason for asking. But I want to share it with the Spackle authors first before I say anything else.
Sounds interesting.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 4, 2013 at 9:40 am
Maybe I'm committing an egregious social error by raising something technical in this forum, but sometimes I thing deprecation lists are at least as political as technical, besides which the people whose opinions n this one are worth having and mostly people who show up here anyway.
Looking at the current version of the deprecation list, I noticed something that rather worries me. Apparently 3 and 4 part column references will be dropped in some version after SQL Server 2014. I realise of course that one can provide single part aliases in the FROM clause of select or the INTO and TARGET clauses of MERGE or the first FROM clause of DELETE or the <object> parameter of UPDATE (or the FROM clause of UPDATE or the second FROM clause of DELETE, at least until the nay-sayers get their way and have THOSE clauses deprecated too), so that nothing is lost in terms of what can be expressed by the language; but clarity counts too, expressiveness is not the only consideration.
It seems to me that this is throwing away clarity. even worse, it's reducing the possibility of providing code with good clarity. Unless people construct aliases that effectively mimic the more than two part column name structure, with the "." (except the last one) replaced by something else - and it is of course impossible to select a "something else" that can't occur in a column name or a schema name, so that could add to obscurity instead of to clarity - so that it is still possible to see at a glance where a column comes from, it will be much harder to see what the code is doing; and since throwing away clarity in code (other than when taking part in a code obfuscation competition :hehe:) is always a terrible idea, it seems to me that removing a feature so that people who currently have clear code will have to make it less clear, and people who want to write clear code won't be permitted to, is even more terrible.
What do other people think?
Tom
August 4, 2013 at 10:57 am
L' Eomot Inversé (8/4/2013)
Maybe I'm committing an egregious social error by raising something technical in this forum, but sometimes I thing deprecation lists are at least as political as technical, besides which the people whose opinions n this one are worth having and mostly people who show up here anyway.Looking at the current version of the deprecation list, I noticed something that rather worries me. Apparently 3 and 4 part column references will be dropped in some version after SQL Server 2014. I realise of course that one can provide single part aliases in the FROM clause of select or the INTO and TARGET clauses of MERGE or the first FROM clause of DELETE or the <object> parameter of UPDATE (or the FROM clause of UPDATE or the second FROM clause of DELETE, at least until the nay-sayers get their way and have THOSE clauses deprecated too), so that nothing is lost in terms of what can be expressed by the language; but clarity counts too, expressiveness is not the only consideration.
It seems to me that this is throwing away clarity. even worse, it's reducing the possibility of providing code with good clarity. Unless people construct aliases that effectively mimic the more than two part column name structure, with the "." (except the last one) replaced by something else - and it is of course impossible to select a "something else" that can't occur in a column name or a schema name, so that could add to obscurity instead of to clarity - so that it is still possible to see at a glance where a column comes from, it will be much harder to see what the code is doing; and since throwing away clarity in code (other than when taking part in a code obfuscation competition :hehe:) is always a terrible idea, it seems to me that removing a feature so that people who currently have clear code will have to make it less clear, and people who want to write clear code won't be permitted to, is even more terrible.
What do other people think?
So this is just an enforcement of aliasing? The full 3 and 4 part naming convention is still fine in the FROM clause, but you have to alias it to reference it in the SELECT clause? Honestly, I like that. I find using the full naming in the SELECT clause to be unreadable. It makes your queries 3 times as long (or longer) and it is harder to pick out the column name from all the Server.Database.Schema debris. I think it makes it much clearer to have easily identifiable aliases instead of the full name. Much like I'd rather call someone "Mike" instead of "Michael Tiberius Flanagan-Krzywicki the Third" every time I say their name.
--------------------------------------
When you encounter a problem, if the solution isn't readily evident go back to the start and check your assumptions.
--------------------------------------
It’s unpleasantly like being drunk.
What’s so unpleasant about being drunk?
You ask a glass of water. -- Douglas Adams
August 4, 2013 at 12:37 pm
Stefan Krzywicki (8/4/2013)
L' Eomot Inversé (8/4/2013)
Maybe I'm committing an egregious social error by raising something technical in this forum, but sometimes I thing deprecation lists are at least as political as technical, besides which the people whose opinions n this one are worth having and mostly people who show up here anyway.Looking at the current version of the deprecation list, I noticed something that rather worries me. Apparently 3 and 4 part column references will be dropped in some version after SQL Server 2014. I realise of course that one can provide single part aliases in the FROM clause of select or the INTO and TARGET clauses of MERGE or the first FROM clause of DELETE or the <object> parameter of UPDATE (or the FROM clause of UPDATE or the second FROM clause of DELETE, at least until the nay-sayers get their way and have THOSE clauses deprecated too), so that nothing is lost in terms of what can be expressed by the language; but clarity counts too, expressiveness is not the only consideration.
It seems to me that this is throwing away clarity. even worse, it's reducing the possibility of providing code with good clarity. Unless people construct aliases that effectively mimic the more than two part column name structure, with the "." (except the last one) replaced by something else - and it is of course impossible to select a "something else" that can't occur in a column name or a schema name, so that could add to obscurity instead of to clarity - so that it is still possible to see at a glance where a column comes from, it will be much harder to see what the code is doing; and since throwing away clarity in code (other than when taking part in a code obfuscation competition :hehe:) is always a terrible idea, it seems to me that removing a feature so that people who currently have clear code will have to make it less clear, and people who want to write clear code won't be permitted to, is even more terrible.
What do other people think?
So this is just an enforcement of aliasing? The full 3 and 4 part naming convention is still fine in the FROM clause, but you have to alias it to reference it in the SELECT clause? Honestly, I like that. I find using the full naming in the SELECT clause to be unreadable. It makes your queries 3 times as long (or longer) and it is harder to pick out the column name from all the Server.Database.Schema debris. I think it makes it much clearer to have easily identifiable aliases instead of the full name. Much like I'd rather call someone "Mike" instead of "Michael Tiberius Flanagan-Krzywicki the Third" every time I say their name.
I'm one of "those" that has been enforcing the 2 part naming convention is the SELECT list since I can remember. Before the advent of SYNONYMs in SQL Server, we used to make "pass through" views to be able to "talk" to tables in other databases. The big reasons for this were not only the decluttering of code but to also make it so you didn't need to change any code if the name of a database changed.
That, notwithstanding, I don't understand why MS is doing this nor do I understand the reasoning behind a great many of the deprecations they've heaped upon us over the years. What the hell is the matter with having a choice? Why is it that with virtually every new version of SQL Server, you have to go back and rework code even on the ANSI compliant side of the house?
On the opposite side of the coin, why is that when an "improvement" is made that it's not made "all the way"? PIVOT still falls woefully short of the full functionality that it should have and MS introduced things like SUM() OVER without it being fully functional. I guess that's why they call it "agile programming"... you have to be "agile" enough to bend over backwards to actually use it. 😛
Heh... and then there are the "improvements" that were once there, were taken away, and then reintroduced as a "new" feature. Hekaton is a prime example of that. Remember being able to PIN TABLE and then took that wonderful feature away? Now they're bringing a form of it back with Hekaton but with more restrictions on use.
It's funny that "deprecation" came up today on this thread. There must be "a great disturbance in the Force" because I had just added another line this morning to my signature here on SSC describing the overall problem and frustration I have about all of this...
"Change is inevitable. Change for the better is not." 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
August 4, 2013 at 7:24 pm
Jeff Moden (8/4/2013)[hrThere must be "a great disturbance in the Force" because I had just added another line this morning to my signature here on SSC describing the overall problem and frustration I have about all of this...
"Change is inevitable. Change for the better is not." 😉
I like it - almost enough to copy it.
Tom
August 5, 2013 at 12:47 am
Brandie Tarvin (8/2/2013)
How many people (besides Jeff and myself) have written SQL Spackle articles?How many SQL Spackle articles are there?
Yes, I have a reason for asking. But I want to share it with the Spackle authors first before I say anything else.
I'm currently working on one. The Cascading CROSS APPLY began as a Spackle article too but grew too long.
For fast, accurate and documented assistance in answering your questions, please read this article.
Understanding and using APPLY, (I) and (II) Paul White
Hidden RBAR: Triangular Joins / The "Numbers" or "Tally" Table: What it is and how it replaces a loop Jeff Moden
August 5, 2013 at 2:14 am
Jeff Moden (8/4/2013)
Remember being able to PIN TABLE and then took that wonderful feature away? Now they're bringing a form of it back with Hekaton but with more restrictions on use.
Pin Table != Hekaton. Not even close.
All pin table did was ensure that a table remained in cache, just as if it were a hot table that's constantly used. No other optimisations, no reductions in writes to log or data file and the problem that depending what you try to pin you could absolutely cripple performance (imagine pinning a 2GB table on a server that only had 3 GB memory just because the DBA had been told that it was a wonderful feature that should be used on busy tables)
It wasn't that great a feature. Used on a table that was heavily used it would have little effect as a heavily used table tends to stay in cache (the heavily used portions anyway), used on a seldom used table it's taking memory that's not needed.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
August 5, 2013 at 5:06 am
L' Eomot Inversé (8/4/2013)
Looking at the current version of the deprecation list, I noticed something that rather worries me. Apparently 3 and 4 part column references will be dropped in some version after SQL Server 2014. I realise of course that one can provide single part aliases in the FROM clause of select or the INTO and TARGET clauses of MERGE or the first FROM clause of DELETE or the <object> parameter of UPDATE (or the FROM clause of UPDATE or the second FROM clause of DELETE, at least until the nay-sayers get their way and have THOSE clauses deprecated too), so that nothing is lost in terms of what can be expressed by the language; but clarity counts too, expressiveness is not the only consideration.It seems to me that this is throwing away clarity. even worse, it's reducing the possibility of providing code with good clarity. Unless people construct aliases that effectively mimic the more than two part column name structure, with the "." (except the last one) replaced by something else - and it is of course impossible to select a "something else" that can't occur in a column name or a schema name, so that could add to obscurity instead of to clarity - so that it is still possible to see at a glance where a column comes from, it will be much harder to see what the code is doing; and since throwing away clarity in code (other than when taking part in a code obfuscation competition :hehe:) is always a terrible idea, it seems to me that removing a feature so that people who currently have clear code will have to make it less clear, and people who want to write clear code won't be permitted to, is even more terrible.
What do other people think?
I think either I'm really really tired or I'm not quite understanding what you're saying. Quite possibly both.
Do you have examples or links that you can point to so I can better understand what you are talking about?
August 5, 2013 at 6:01 am
... Remember being able to PIN TABLE ...
:exclamation: you have no idea how happy I am that vendors do not have access to that
I'm a DBA.
I'm not paid to solve problems. I'm paid to prevent them.
August 5, 2013 at 8:00 am
andrew gothard (8/5/2013)
... Remember being able to PIN TABLE ...
:exclamation: you have no idea how happy I am that vendors do not have access to that
And clients....
I remember finding that in the bank's main DB when I first started there. The overall performance gain I got from unpinning all the tables was quite large.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
August 5, 2013 at 9:45 am
GilaMonster (8/5/2013)
andrew gothard (8/5/2013)
... Remember being able to PIN TABLE ...
:exclamation: you have no idea how happy I am that vendors do not have access to that
And clients....
I remember finding that in the bank's main DB when I first started there. The overall performance gain I got from unpinning all the tables was quite large.
As a consultant, I'd think you'd want every company to have this ability, and every DBA/developer to have access. Very good for business :w00t:
August 5, 2013 at 9:51 am
Steve Jones - SSC Editor (8/5/2013)
GilaMonster (8/5/2013)
andrew gothard (8/5/2013)
... Remember being able to PIN TABLE ...
:exclamation: you have no idea how happy I am that vendors do not have access to that
And clients....
I remember finding that in the bank's main DB when I first started there. The overall performance gain I got from unpinning all the tables was quite large.
As a consultant, I'd think you'd want every company to have this ability, and every DBA/developer to have access. Very good for business :w00t:
That type of thinking has led me to change my view on cursors as well. Telling people, "I love cursors" usually gets me a strange look... until I finish the sentence.
Viewing 15 posts - 40,756 through 40,770 (of 66,816 total)
You must be logged in to reply to this topic. Login to reply