June 6, 2008 at 4:03 am
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?
June 6, 2008 at 6:37 am
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.
June 6, 2008 at 7:57 am
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
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
June 6, 2008 at 9:12 am
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
June 6, 2008 at 12:24 pm
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
June 6, 2008 at 1:05 pm
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
Consultant - Straight Path Solutions
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
June 6, 2008 at 1:19 pm
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
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
June 1, 2009 at 7:52 pm
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
June 8, 2009 at 7:38 pm
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 ...
June 9, 2009 at 3:35 am
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
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply