SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


display order by like 1,2,3,4,5...............plz write quarie


display order by like 1,2,3,4,5...............plz write quarie

Author
Message
dwain.c
dwain.c
SSCertifiable
SSCertifiable (7.2K reputation)SSCertifiable (7.2K reputation)SSCertifiable (7.2K reputation)SSCertifiable (7.2K reputation)SSCertifiable (7.2K reputation)SSCertifiable (7.2K reputation)SSCertifiable (7.2K reputation)SSCertifiable (7.2K reputation)

Group: General Forum Members
Points: 7213 Visits: 6431
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!
My temporal SQL musings: Calendar Tables, an Easter SQL, Time Slots and Self-maintaining, Contiguous Effective Dates in Temporal Tables
Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (84K reputation)SSC Guru (84K reputation)SSC Guru (84K reputation)SSC Guru (84K reputation)SSC Guru (84K reputation)SSC Guru (84K reputation)SSC Guru (84K reputation)SSC Guru (84K reputation)

Group: General Forum Members
Points: 84959 Visits: 41071
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.
If you think its expensive to hire a professional to do the job, wait until you hire an amateur. -- Red Adair

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
dwain.c
dwain.c
SSCertifiable
SSCertifiable (7.2K reputation)SSCertifiable (7.2K reputation)SSCertifiable (7.2K reputation)SSCertifiable (7.2K reputation)SSCertifiable (7.2K reputation)SSCertifiable (7.2K reputation)SSCertifiable (7.2K reputation)SSCertifiable (7.2K reputation)

Group: General Forum Members
Points: 7213 Visits: 6431
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!
My temporal SQL musings: Calendar Tables, an Easter SQL, Time Slots and Self-maintaining, Contiguous Effective Dates in Temporal Tables
GilaMonster
GilaMonster
SSC Guru
SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)

Group: General Forum Members
Points: 86490 Visits: 45240
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, MVP, M.Sc (Comp Sci)
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


Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (84K reputation)SSC Guru (84K reputation)SSC Guru (84K reputation)SSC Guru (84K reputation)SSC Guru (84K reputation)SSC Guru (84K reputation)SSC Guru (84K reputation)SSC Guru (84K reputation)

Group: General Forum Members
Points: 84959 Visits: 41071
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. Sick

--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.
If you think its expensive to hire a professional to do the job, wait until you hire an amateur. -- Red Adair

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
dwain.c
dwain.c
SSCertifiable
SSCertifiable (7.2K reputation)SSCertifiable (7.2K reputation)SSCertifiable (7.2K reputation)SSCertifiable (7.2K reputation)SSCertifiable (7.2K reputation)SSCertifiable (7.2K reputation)SSCertifiable (7.2K reputation)SSCertifiable (7.2K reputation)

Group: General Forum Members
Points: 7213 Visits: 6431
For what it's worth, I'm in favor of a selective culling of the gene pool. :-P


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!
My temporal SQL musings: Calendar Tables, an Easter SQL, Time Slots and Self-maintaining, Contiguous Effective Dates in Temporal Tables
Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (84K reputation)SSC Guru (84K reputation)SSC Guru (84K reputation)SSC Guru (84K reputation)SSC Guru (84K reputation)SSC Guru (84K reputation)SSC Guru (84K reputation)SSC Guru (84K reputation)

Group: General Forum Members
Points: 84959 Visits: 41071
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.
If you think its expensive to hire a professional to do the job, wait until you hire an amateur. -- Red Adair

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (84K reputation)SSC Guru (84K reputation)SSC Guru (84K reputation)SSC Guru (84K reputation)SSC Guru (84K reputation)SSC Guru (84K reputation)SSC Guru (84K reputation)SSC Guru (84K reputation)

Group: General Forum Members
Points: 84959 Visits: 41071
dwain.c (11/5/2013)
For what it's worth, I'm in favor of a selective culling of the gene pool. :-P


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.
If you think its expensive to hire a professional to do the job, wait until you hire an amateur. -- Red Adair

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
dwain.c
dwain.c
SSCertifiable
SSCertifiable (7.2K reputation)SSCertifiable (7.2K reputation)SSCertifiable (7.2K reputation)SSCertifiable (7.2K reputation)SSCertifiable (7.2K reputation)SSCertifiable (7.2K reputation)SSCertifiable (7.2K reputation)SSCertifiable (7.2K reputation)

Group: General Forum Members
Points: 7213 Visits: 6431
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. :-P


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!
My temporal SQL musings: Calendar Tables, an Easter SQL, Time Slots and Self-maintaining, Contiguous Effective Dates in Temporal Tables
Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (84K reputation)SSC Guru (84K reputation)SSC Guru (84K reputation)SSC Guru (84K reputation)SSC Guru (84K reputation)SSC Guru (84K reputation)SSC Guru (84K reputation)SSC Guru (84K reputation)

Group: General Forum Members
Points: 84959 Visits: 41071
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. :-P


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.
If you think its expensive to hire a professional to do the job, wait until you hire an amateur. -- Red Adair

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search