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 ««1234»»»

display order by like 1,2,3,4,5...............plz write quarie Expand / Collapse
Author
Message
Posted Monday, November 4, 2013 11:00 PM


Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Yesterday @ 7:58 PM
Points: 3,422, Visits: 5,366
Jeff Moden (11/4/2013)
shashianireddy (11/4/2013)
sql 2008 version ,,nvarchar(MAX)


You're using NVARCHAR(MAX) for a housenumber???? In SQL Server 2008???? Why?????

You probably don't release it but you cannot rebuild a clustered index in an Online fashion in SQL Server 2008 if the table contains a blob. This is a totally unneccessary blob.

Yes, yes... I know... all of your character based columns are NVARCHAR(MAX) because someone believes that "Premature optimization is the root of all evil." The problem is no one ever considers such things as what I've just mentioned and even fewer go back and optimize when they're supposed to.

I strongly recommend that someone go fix that table to have the correctly sized datatypes.


Glad to see I'm not the only one that felt that way. Although your feelings seem a bit stronger on the subject. Probably because you're not seeing such nonsense as frequently as I do.



My mantra: No loops! No CURSORs! No RBAR! Hoo-uh!

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?
Since random numbers are too important to be left to chance, let's generate some!
Learn to understand recursive CTEs by example.
Splitting strings based on patterns can be fast!
Post #1511363
Posted Monday, November 4, 2013 11:09 PM


SSC-Dedicated

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

Group: General Forum Members
Last Login: Today @ 9:34 AM
Points: 35,532, Visits: 32,115
dwain.c (11/4/2013)
Jeff Moden (11/4/2013)
shashianireddy (11/4/2013)
sql 2008 version ,,nvarchar(MAX)


You're using NVARCHAR(MAX) for a housenumber???? In SQL Server 2008???? Why?????

You probably don't release it but you cannot rebuild a clustered index in an Online fashion in SQL Server 2008 if the table contains a blob. This is a totally unneccessary blob.

Yes, yes... I know... all of your character based columns are NVARCHAR(MAX) because someone believes that "Premature optimization is the root of all evil." The problem is no one ever considers such things as what I've just mentioned and even fewer go back and optimize when they're supposed to.

I strongly recommend that someone go fix that table to have the correctly sized datatypes.


Glad to see I'm not the only one that felt that way. Although your feelings seem a bit stronger on the subject. Probably because you're not seeing such nonsense as frequently as I do.


The reason why I don't see such nonsense that often is because I've trained my Developers. I would never allow such a table design to even go into Dev never mind Prod. This is the kind of garbage that some of the automatic front-end designer software does. What really kills me is that one of the products that does it is Microsoft software.

I'm all for the avoidance of prematue optimization but any system or human that creates all NVARCHAR(MAX) or even all NVARCHAR(4000) for all character based columns in a table is way over the top so far as I'm concerned.


--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 #1511364
Posted Monday, November 4, 2013 11:24 PM


Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Yesterday @ 7:58 PM
Points: 3,422, Visits: 5,366
Jeff Moden (11/4/2013)
dwain.c (11/4/2013)
Jeff Moden (11/4/2013)
shashianireddy (11/4/2013)
sql 2008 version ,,nvarchar(MAX)


You're using NVARCHAR(MAX) for a housenumber???? In SQL Server 2008???? Why?????

You probably don't release it but you cannot rebuild a clustered index in an Online fashion in SQL Server 2008 if the table contains a blob. This is a totally unneccessary blob.

Yes, yes... I know... all of your character based columns are NVARCHAR(MAX) because someone believes that "Premature optimization is the root of all evil." The problem is no one ever considers such things as what I've just mentioned and even fewer go back and optimize when they're supposed to.

I strongly recommend that someone go fix that table to have the correctly sized datatypes.


Glad to see I'm not the only one that felt that way. Although your feelings seem a bit stronger on the subject. Probably because you're not seeing such nonsense as frequently as I do.


The reason why I don't see such nonsense that often is because I've trained my Developers. I would never allow such a table design to even go into Dev never mind Prod. This is the kind of garbage that some of the automatic front-end designer software does. What really kills me is that one of the products that does it is Microsoft software.

I'm all for the avoidance of prematue optimization but any system or human that creates all NVARCHAR(MAX) or even all NVARCHAR(4000) for all character based columns in a table is way over the top so far as I'm concerned.


Sounds like you have the luxury of an orderly, controlled shop. Congratulations for exercising such strict controls (and being able to)!



My mantra: No loops! No CURSORs! No RBAR! Hoo-uh!

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?
Since random numbers are too important to be left to chance, let's generate some!
Learn to understand recursive CTEs by example.
Splitting strings based on patterns can be fast!
Post #1511367
Posted Monday, November 4, 2013 11:35 PM


SSC-Forever

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

Group: General Forum Members
Last Login: Yesterday @ 2:01 PM
Points: 40,390, Visits: 36,823
Jeff Moden (11/4/2013)
Yes, yes... I know... all of your character based columns are NVARCHAR(MAX) because someone believes that "Premature optimization is the root of all evil." The problem is no one ever considers such things as what I've just mentioned and even fewer go back and optimize when they're supposed to.


Premature optimisation IS the root of all evil. This is not premature optimisation. This is poor data type choice. Premature optimisation would be something like selecting char over varchar because someone heard it's faster and didn't do any evaluations to see if it is or if there's a performance problem in the first place.

Premature optimisation is making weird data type or design choices because 'they're faster' without any testing or any consideration as to whether any imagined or real performance problems exist, resulting in a more complex or strange design that's harder to maintain or even slower than it could be.



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 #1511368
Posted Tuesday, November 5, 2013 12:03 AM


SSC-Dedicated

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

Group: General Forum Members
Last Login: Today @ 9:34 AM
Points: 35,532, Visits: 32,115
GilaMonster (11/4/2013)
Jeff Moden (11/4/2013)
Yes, yes... I know... all of your character based columns are NVARCHAR(MAX) because someone believes that "Premature optimization is the root of all evil." The problem is no one ever considers such things as what I've just mentioned and even fewer go back and optimize when they're supposed to.


Premature optimisation IS the root of all evil. This is not premature optimisation. This is poor data type choice. Premature optimisation would be something like selecting char over varchar because someone heard it's faster and didn't do any evaluations to see if it is or if there's a performance problem in the first place.

Premature optimisation is making weird data type or design choices because 'they're faster' without any testing or any consideration as to whether any imagined or real performance problems exist, resulting in a more complex or strange design that's harder to maintain or even slower than it could be.


I'm well aware of that. You and I have had this conversation before and I absolutely agree. I should have said "and that someone is wrong because making good choices as to data type is NOT a pre-optimization."

My biggest problem with Mr. Knuth's fine words isn't with the words. It's with how people have tainted the meaning of the words. I had an "expert" "developer" look me straight in the face when I asked him why he designed a table with all of the character-based columns (even a Zip Code column!) as NVARCHAR(4000) and tell me that "Pre-Optimisation is the root of all evil". If I were a lesser man, I'd have killed him on the spot to end that particular gene pool.

I have the same problem with such "expert" "developers" that think that Agile methods mean that you don't have to document your code.


--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 #1511375
Posted Tuesday, November 5, 2013 12:17 AM


Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Yesterday @ 7:58 PM
Points: 3,422, Visits: 5,366
For what it's worth, I'm in favor of a selective culling of the gene pool.


My mantra: No loops! No CURSORs! No RBAR! Hoo-uh!

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?
Since random numbers are too important to be left to chance, let's generate some!
Learn to understand recursive CTEs by example.
Splitting strings based on patterns can be fast!
Post #1511379
Posted Tuesday, November 5, 2013 12:39 AM


SSC-Dedicated

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

Group: General Forum Members
Last Login: Today @ 9:34 AM
Points: 35,532, Visits: 32,115
dwain.c (11/4/2013)

Sounds like you have the luxury of an orderly, controlled shop. Congratulations for exercising such strict controls (and being able to)!


I don't think of them as strict controls although I can certainly see why some people might. I'm actually terribly concerned that I've had to implement such controls in virtually every shop I've worked in. I just don't understand why these types of things aren't just common sense. I actually hate having to implement such controls because they take a huge amount of my time. The only good things about such controls is that they do give me one-on-one time with each Developer so that I can do a little mentoring and the code that comes out of the end of the process.


--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 #1511382
Posted Tuesday, November 5, 2013 1:01 AM


SSC-Dedicated

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

Group: General Forum Members
Last Login: Today @ 9:34 AM
Points: 35,532, Visits: 32,115
dwain.c (11/5/2013)
For what it's worth, I'm in favor of a selective culling of the gene pool.


I assure you, it's just words from some serious pent up frustration from working with some folks that don't get it. Rest assurred that I take the high road and try to educate them. I'm not always successful but I do try.


--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 #1511385
Posted Tuesday, November 5, 2013 1:13 AM


Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Yesterday @ 7:58 PM
Points: 3,422, Visits: 5,366
Jeff Moden (11/5/2013)
dwain.c (11/5/2013)
For what it's worth, I'm in favor of a selective culling of the gene pool.


I assure you, it's just words from some serious pent up frustration from working with some folks that don't get it. Rest assurred that I take the high road and try to educate them. I'm not always successful but I do try.


And if you fail, that's when you break out the high-velocity pork chops I presume.



My mantra: No loops! No CURSORs! No RBAR! Hoo-uh!

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?
Since random numbers are too important to be left to chance, let's generate some!
Learn to understand recursive CTEs by example.
Splitting strings based on patterns can be fast!
Post #1511388
Posted Tuesday, November 5, 2013 1:22 AM


SSC-Dedicated

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

Group: General Forum Members
Last Login: Today @ 9:34 AM
Points: 35,532, Visits: 32,115
dwain.c (11/5/2013)
Jeff Moden (11/5/2013)
dwain.c (11/5/2013)
For what it's worth, I'm in favor of a selective culling of the gene pool.


I assure you, it's just words from some serious pent up frustration from working with some folks that don't get it. Rest assurred that I take the high road and try to educate them. I'm not always successful but I do try.


And if you fail, that's when you break out the high-velocity pork chops I presume.


Nope. In such a case, that would simply be another failure on my part. I've found that the people I'm successful with want to learn. My real failure is sometimes failing to recognize those that don't actually want to learn.


--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 #1511390
« Prev Topic | Next Topic »

Add to briefcase ««1234»»»

Permissions Expand / Collapse