Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase «««4,0754,0764,0774,0784,079»»»

Are the posted questions getting worse? Expand / Collapse
Author
Message
Posted Sunday, August 4, 2013 10:57 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Thursday, August 7, 2014 7:44 PM
Points: 2,762, Visits: 7,235
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 ) 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
Post #1480783
Posted Sunday, August 4, 2013 12:37 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 8:38 AM
Points: 36,979, Visits: 31,502
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 ) 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
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1480785
Posted Sunday, August 4, 2013 7:24 PM


SSCrazy Eights

SSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy Eights

Group: General Forum Members
Last Login: Today @ 8:43 AM
Points: 8,718, Visits: 9,264
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
Post #1480804
Posted Monday, August 5, 2013 12:47 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 9:28 AM
Points: 7,219, Visits: 13,683
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.


“Write the query the simplest way. If through testing it becomes clear that the performance is inadequate, consider alternative query forms.” - Gail Shaw

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
Exploring Recursive CTEs by Example Dwain Camps
Post #1480820
Posted Monday, August 5, 2013 2:14 AM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Today @ 7:56 AM
Points: 42,817, Visits: 35,940
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 2008, MVP
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Post #1480833
Posted Monday, August 5, 2013 5:06 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Monday, August 25, 2014 7:14 AM
Points: 7,197, Visits: 6,341
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 ) 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?


Brandie Tarvin, MCITP Database Administrator

Webpage: http://www.BrandieTarvin.net
LiveJournal Blog: http://brandietarvin.livejournal.com/
On LinkedIn!, Google+, and Twitter.

Freelance Writer: Shadowrun
Latchkeys: Nevermore, Latchkeys: The Bootleg War, and Latchkeys: Roscoes in the Night are now available on Nook and Kindle.
Post #1480874
Posted Monday, August 5, 2013 6:01 AM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Yesterday @ 5:39 AM
Points: 338, Visits: 3,289
... Remember being able to PIN TABLE ...

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.
Post #1480881
Posted Monday, August 5, 2013 8:00 AM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Today @ 7:56 AM
Points: 42,817, Visits: 35,940
andrew gothard (8/5/2013)
... Remember being able to PIN TABLE ...

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 2008, MVP
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Post #1480922
Posted Monday, August 5, 2013 9:45 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Today @ 8:26 AM
Points: 33,191, Visits: 15,331
GilaMonster (8/5/2013)
andrew gothard (8/5/2013)
... Remember being able to PIN TABLE ...

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







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1480973
Posted Monday, August 5, 2013 9:51 AM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Today @ 8:19 AM
Points: 2,607, Visits: 17,927
Steve Jones - SSC Editor (8/5/2013)
GilaMonster (8/5/2013)
andrew gothard (8/5/2013)
... Remember being able to PIN TABLE ...

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


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.
Post #1480979
« Prev Topic | Next Topic »

Add to briefcase «««4,0754,0764,0774,0784,079»»»

Permissions Expand / Collapse