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


Varchar to Char for Performance.


Varchar to Char for Performance.

Author
Message
Ashwin M N
Ashwin M N
Ten Centuries
Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)

Group: General Forum Members
Points: 1418 Visits: 855
I design tables for our projects. I use lot of VARCHAR datatype in my table design(ex: First_name varchar(50),Last_Name varchar(50)). But my project manager suggests that using char field instead of Varchar improves in performance of retrieving the data from the database. My argument is that it unnecessarily consumes 50 bytes of space even though if the first_name is of five characters. But I am not convinced as how changing the datatype from varchar to char improves the performance of retrieving the data from the database?
Michael Earl-395764
Michael Earl-395764
SSChampion
SSChampion (13K reputation)SSChampion (13K reputation)SSChampion (13K reputation)SSChampion (13K reputation)SSChampion (13K reputation)SSChampion (13K reputation)SSChampion (13K reputation)SSChampion (13K reputation)

Group: General Forum Members
Points: 13609 Visits: 23078
In columns in which the length does not vary greatly, you could see a performance increase using CHAR vs. VARCHAR because many operations against fixed width data are faster.

However, data like names, in which the length varies heavily and you are probably not doing joins to other tables you will see no performance difference and will probably end up with an overall performance degredation because your application will probably have to constantly deal with trimming white space - or even passing around bloated data sets full of trailing spaces that just eat up bandwidth.

So, I would say a field that is going to hold a US zipcode - CHAR(5) and then a VARCHAR(4) for the +4 unless you actually have most of your customers' +4 values.
Grant Fritchey
Grant Fritchey
SSC Guru
SSC Guru (100K reputation)SSC Guru (100K reputation)SSC Guru (100K reputation)SSC Guru (100K reputation)SSC Guru (100K reputation)SSC Guru (100K reputation)SSC Guru (100K reputation)SSC Guru (100K reputation)

Group: General Forum Members
Points: 100211 Visits: 33014
The performance increase is pretty small in most cases, but it is there. It really depends though, if the data is fixed length, you should use CHAR/NCHAR for it. If it's variable length, while data access is sped up slightly, you're increasing storage and network traffic (moving all those empty spaces around) for not much gain. Time spent tuning indexes and writing good TSQL code will be worth a heck of a lot more than worrying about the performance difference between VARCHAR(50) and CHAR(50).

----------------------------------------------------
The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood...
Theodore Roosevelt

The Scary DBA
Author of: SQL Server Query Performance Tuning and SQL Server Execution Plans
Product Evangelist for Red Gate Software
GSquared
GSquared
SSC Guru
SSC Guru (59K reputation)SSC Guru (59K reputation)SSC Guru (59K reputation)SSC Guru (59K reputation)SSC Guru (59K reputation)SSC Guru (59K reputation)SSC Guru (59K reputation)SSC Guru (59K reputation)

Group: General Forum Members
Points: 59287 Visits: 9730
The rule of thumb I use is, if the field is 10 or less characters wide, I use char, for anything bigger, if it will vary in width, I use varchar. That's kind of arbitrary, but it's worked well for me.

As Grant mentioned, worrying about the performance difference between char and varchar is pretty meaningless in most situations. Almost always, you're much better off paying attention to code and data structure, to get better performance. After that, I'd prioritize hardware configuration. Then, maybe, worry about data types. Maybe.

- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread

"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
noeld
noeld
SSC-Insane
SSC-Insane (23K reputation)SSC-Insane (23K reputation)SSC-Insane (23K reputation)SSC-Insane (23K reputation)SSC-Insane (23K reputation)SSC-Insane (23K reputation)SSC-Insane (23K reputation)SSC-Insane (23K reputation)

Group: General Forum Members
Points: 23250 Visits: 2048
This is one of those "premature" optimization tips that wander around and that actually makes very little difference except on very (and I mean very) specific cases.


* Noel
Jack Corbett
  Jack Corbett
SSC-Forever
SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)

Group: General Forum Members
Points: 45753 Visits: 14925
Good advice all around. The only thing I will add is that you need to make sure trailing blanks are removed on insert from varchar fields as the ANSI PADDING standard keeps trailing blanks in storage and this does also have some affect on other operations.



Jack Corbett

Applications Developer

Don't let the good be the enemy of the best. -- Paul Fleming
At best you can say that one job may be more secure than another, but total job security is an illusion. -- Rod at work

Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
How to Post Performance Problems
Crosstabs and Pivots or How to turn rows into columns Part 1
Crosstabs and Pivots or How to turn rows into columns Part 2
Grant Fritchey
Grant Fritchey
SSC Guru
SSC Guru (100K reputation)SSC Guru (100K reputation)SSC Guru (100K reputation)SSC Guru (100K reputation)SSC Guru (100K reputation)SSC Guru (100K reputation)SSC Guru (100K reputation)SSC Guru (100K reputation)

Group: General Forum Members
Points: 100211 Visits: 33014
Of course the next thing you should worry about is stacking all the fixed length, non-nullable fields at the front of the page... There's a lot of things you can do to squeeze an extra MS or two out of storage & retrieval. Except, in very rare circumstances, they just don't matter to most systems.

----------------------------------------------------
The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood...
Theodore Roosevelt

The Scary DBA
Author of: SQL Server Query Performance Tuning and SQL Server Execution Plans
Product Evangelist for Red Gate Software
Ol'SureHand
Ol'SureHand
SSC Eights!
SSC Eights! (881 reputation)SSC Eights! (881 reputation)SSC Eights! (881 reputation)SSC Eights! (881 reputation)SSC Eights! (881 reputation)SSC Eights! (881 reputation)SSC Eights! (881 reputation)SSC Eights! (881 reputation)

Group: General Forum Members
Points: 881 Visits: 720
Was: Trying to revive this topic from the DATASPACE point of view rather than create a new one.
---- please see new topic VARCHAR vs CHAR - Table Dataspace SQL2005
Ol'SureHand
Ol'SureHand
SSC Eights!
SSC Eights! (881 reputation)SSC Eights! (881 reputation)SSC Eights! (881 reputation)SSC Eights! (881 reputation)SSC Eights! (881 reputation)SSC Eights! (881 reputation)SSC Eights! (881 reputation)SSC Eights! (881 reputation)

Group: General Forum Members
Points: 881 Visits: 720
Is there anyone able & willing to assist with an explanation: why VARCHAR(35) seems to take more space than CHAR(35) even with trimmed blanks?
Previous post explains circumstances. Not sure if to create a new topic ...
GilaMonster
GilaMonster
SSC Guru
SSC Guru (230K reputation)SSC Guru (230K reputation)SSC Guru (230K reputation)SSC Guru (230K reputation)SSC Guru (230K reputation)SSC Guru (230K reputation)SSC Guru (230K reputation)SSC Guru (230K reputation)

Group: General Forum Members
Points: 230572 Visits: 46346
Ol'SureHand (6/8/2009)
Not sure if to create a new topic ...

Please do.

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


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