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

Varchar to Char for Performance. Expand / Collapse
Author
Message
Posted Friday, June 6, 2008 4:03 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Tuesday, August 13, 2013 12:34 AM
Points: 966, 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?
Post #512771
Posted Friday, June 6, 2008 6:37 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Tuesday, August 10, 2010 5:07 AM
Points: 2,732, Visits: 23,078
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.
Post #512842
Posted Friday, June 6, 2008 7:57 AM


SSCoach

SSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoach

Group: General Forum Members
Last Login: Today @ 1:03 PM
Points: 15,729, Visits: 28,132
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 2012 Query Performance Tuning
SQL Server 2008 Query Performance Tuning Distilled
and
SQL Server Execution Plans

Product Evangelist for Red Gate Software
Post #512914
Posted Friday, June 6, 2008 9:12 AM


SSCoach

SSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoach

Group: General Forum Members
Last Login: Friday, June 27, 2014 12:43 PM
Points: 15,444, Visits: 9,596
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
Post #513000
Posted Friday, June 6, 2008 12:24 PM
SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 5:47 AM
Points: 6,266, Visits: 2,029
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
Post #513134
Posted Friday, June 6, 2008 1:05 PM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Today @ 12:45 PM
Points: 11,305, Visits: 13,093
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

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
Post #513166
Posted Friday, June 6, 2008 1:19 PM


SSCoach

SSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoach

Group: General Forum Members
Last Login: Today @ 1:03 PM
Points: 15,729, Visits: 28,132
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 2012 Query Performance Tuning
SQL Server 2008 Query Performance Tuning Distilled
and
SQL Server Execution Plans

Product Evangelist for Red Gate Software
Post #513176
Posted Monday, June 1, 2009 7:52 PM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Wednesday, September 3, 2014 1:12 AM
Points: 370, Visits: 716
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
Post #727089
Posted Monday, June 8, 2009 7:38 PM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Wednesday, September 3, 2014 1:12 AM
Points: 370, Visits: 716
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 ...
Post #731072
Posted Tuesday, June 9, 2009 3:35 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 @ 1:06 PM
Points: 43,007, Visits: 36,161
Ol'SureHand (6/8/2009)
Not sure if to create a new topic ...

Please do.



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

Add to briefcase

Permissions Expand / Collapse