Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.
Solved
Should I always use VARCHAR
Posted on 2011-02-15
VARCHAR requires 1 bytes per character
NVARCHAR requires 2 bytes per character
Should I always use VARCHAR
[X]
Welcome to Experts Exchange
Add your voice to the tech community where 5M+ people just like you are talking about what matters.
- Help others & share knowledge
- Earn cash & points
- Learn & ask questions
6 Comments
look this one on stack overflow.
http://stackoverflow.com/questions/35366/varchar-vs-nvarchar-performance
http://stackoverflow.com/questions/35366/varchar-vs-nvarchar-performance
If I'm not mistaken, varchar will reserve the whole space for your field, while nvarchar will reserve space dinamically.
So, if you have a varchar(50), it will ocupy always 50 bytes, while a nvarchar(50) will ocupy 10 bytes when you store a record with 5 chars and 20 bytes when you store a record with 10 chars.
varchar will reserve space even for empty (and maybe null, but I'm not really sure) records. So, in the long term, usually nvarchar will allow you to save space except on fields where you are very aware of the chars that is used (IDs, phones, etc...).
So, for strictly inputted data use varchar, and for free text use nvarchar.
So, if you have a varchar(50), it will ocupy always 50 bytes, while a nvarchar(50) will ocupy 10 bytes when you store a record with 5 chars and 20 bytes when you store a record with 10 chars.
varchar will reserve space even for empty (and maybe null, but I'm not really sure) records. So, in the long term, usually nvarchar will allow you to save space except on fields where you are very aware of the chars that is used (IDs, phones, etc...).
So, for strictly inputted data use varchar, and for free text use nvarchar.
>If I'm not mistaken, varchar will reserve the whole space for your field, while nvarchar will reserve space dinamically.
you confuse CHAR vs VARCHAR
CHAR/NCHAR will indeed reserve the space (using trailing spaces)
VARCHAR/NVARCHAR will not reserve space, but only use space as needed.
both will NOT reserve any space if NULL is to be stored.
apart from that, indeed the NCHAR and NVARCHAR will use 2 bytes per character, to allow multi-codepage data to be stored.
you confuse CHAR vs VARCHAR
CHAR/NCHAR will indeed reserve the space (using trailing spaces)
VARCHAR/NVARCHAR will not reserve space, but only use space as needed.
both will NOT reserve any space if NULL is to be stored.
apart from that, indeed the NCHAR and NVARCHAR will use 2 bytes per character, to allow multi-codepage data to be stored.
Mr_Shaw:
the answer for your question is One we can't answer.
We only can tell you the difference and you must decide then what you need/don't need.
char indeed reserves the spaces (1byte / Char)
varchar doesn't reserve the space but will use dynamicaly (1byte / Char)
the nChar and nVarchar are the MultiCode page versions of the 2 above.
For this expansion they indeed need 2 bytes for each char
So Now you need to decide do you need multiCode text to be saved in the database?
Yes : Use the N-Versions
No : Use the normal versions
regards
poor beggar
the answer for your question is One we can't answer.
We only can tell you the difference and you must decide then what you need/don't need.
char indeed reserves the spaces (1byte / Char)
varchar doesn't reserve the space but will use dynamicaly (1byte / Char)
the nChar and nVarchar are the MultiCode page versions of the 2 above.
For this expansion they indeed need 2 bytes for each char
So Now you need to decide do you need multiCode text to be saved in the database?
Yes : Use the N-Versions
No : Use the normal versions
regards
poor beggar
VARCHAR and NVARCHAR require an extra 2 bytes to store the string size. So a 15 character string will require 17 bytes for a VARCHAR and 32 bytes for a NVARCHAR, against 15 bytes for CHAR and 30 bytes for NCHAR.
So to save space I would recommend CHAR/NCHAR for columns that hold attributes that are truly fixed in length (like most codes) or have only 1 or 2 characters (CHAR(1), CHAR(2), NCHAR(1), NCHAR(2)).
So to save space I would recommend CHAR/NCHAR for columns that hold attributes that are truly fixed in length (like most codes) or have only 1 or 2 characters (CHAR(1), CHAR(2), NCHAR(1), NCHAR(2)).
Featured Post
Before moving to the cloud, it is important to carefully define your db needs, plan for the migration & understand prod. environment. This wp explains how to define what you need from a cloud provider, plan for the migration & what putting a cloud solution into practice entails.
Question has a verified solution.
If you are experiencing a similar issue, please ask a related question
The Delta outage: 650 cancelled flights, more than 1200 delayed flights, thousands of frustrated customers, tens of millions of dollars in damages – plus untold reputational damage to one of the world’s most trusted airlines. All due to a catastroph…
In the first part of this tutorial we will cover the prerequisites for installing SQL Server vNext on Linux.
Viewers will learn how to use the SELECT statement in SQL to return specific rows and columns, with various degrees of sorting and limits in place.
Viewers will learn how to use the SELECT statement in SQL and will be exposed to the many uses the SELECT statement has.
Suggested Courses
Course of the Month9 days, 9 hours left to enroll
722 members asked questions and received personalized solutions in the past 7 days.
Join the community of 500,000 technology professionals and ask your questions.