• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

nVarChar vs VarChar

T

TechBoyJK

Lifer
I'm trying to decide if there's any real advantage to using varchar anymore. With diskspace being pretty cheap, and user/app/language support being a real issue, is there any real reason to use varchar? I know it takes up less space than nVarChar, but you lose unicode support and run the risk of some users (maybe in different countries) being able to input data outside the scope of what varchar accepts.
 
Your users should be isolated from your database anyways so them giving invalid input to your database should not pose a problem, they should get an error message from your app.

When you create a database, table, or column you can specify a character set and collation rules. That is what determines what values can be stored. Using a nvarchar('national varchar' in mysql) just informs the DB engine to use a specific defaulted character set. If that character set works then use it, otherwise you need to specify one that works for you. It just so happens that in mysql 'national' == UTF8. CREATE TABLE blah(field varchar(255) CHARACTER SET utf8); is the same as using nvarchar.

Honestly though, if you're writing a web application and only accept ASCII encoded input you're doing it wrong.
 
Crusty said:
Your users should be isolated from your database anyways so them giving invalid input to your database should not pose a problem, they should get an error message from your app.

When you create a database, table, or column you can specify a character set and collation rules. That is what determines what values can be stored. Using a nvarchar('national varchar' in mysql) just informs the DB engine to use a specific defaulted character set. If that character set works then use it, otherwise you need to specify one that works for you. It just so happens that in mysql 'national' == UTF8. CREATE TABLE blah(field varchar(255) CHARACTER SET utf8); is the same as using nvarchar.

Honestly though, if you're writing a web application and only accept ASCII encoded input you're doing it wrong.
Click to expand...

That's kind of what I think.. By limiting text input to varchar for an app that could be hit from anywhere on the globe is basically limiting the functionality and looking for problems. Everything I'm reading is that if you have a remote chance of international users and aren't hard up for disk space, the smart thing to do would be to use nVarChar.
 
TechBoyJK said:
That's kind of what I think.. By limiting text input to varchar for an app that could be hit from anywhere on the globe is basically limiting the functionality and looking for problems. Everything I'm reading is that if you have a remote chance of international users and aren't hard up for disk space, the smart thing to do would be to use nVarChar.
Click to expand...

I might not necessarily use nvarchar in every case. it depends on the dbms. for example, in oracle (you'll have to excuse me, I'm an oracle dba) there both a database character set, and a national character set.
if default settings are not changed, the national character set is atlutf16. (this encompasses just about every possible character that exists)
however, the standard varchar/clob columns will derive their encoding from the database character set.
for 99% of the cases, atlutf8 will suffice and then in all sense their is no difference except one critical one:
utf16 is a four byte encoding. that means that for all sense, you'll only be able to insert 1000 Unicode characters. utf8 will allow 2000.

thus, there is a difference beyond just "aww fuck it! storage is cheap".
 
ForumMaster said:
I might not necessarily use nvarchar in every case. it depends on the dbms. for example, in oracle (you'll have to excuse me, I'm an oracle dba) there both a database character set, and a national character set.
if default settings are not changed, the national character set is atlutf16. (this encompasses just about every possible character that exists)
however, the standard varchar/clob columns will derive their encoding from the database character set.
for 99% of the cases, atlutf8 will suffice and then in all sense their is no difference except one critical one:
utf16 is a four byte encoding. that means that for all sense, you'll only be able to insert 1000 Unicode characters. utf8 will allow 2000.

thus, there is a difference beyond just "aww fuck it! storage is cheap".
Click to expand...

I cringe every time I see a mysql database with 'latin1_swidesh_ci' as the character set. D:
 
I only use varchar for internal stuff that I know is not going to need wide characters, and even that use is becoming pretty uncommon. For anything that is input by or returned to the user I utilize nvarchar.
 
Crusty said:
I cringe every time I see a mysql database with 'latin1_swidesh_ci' as the character set. D:
Click to expand...

i agree 100%. for 99.9% of our oracle database, the database character set is atl32utf8. i don't care whether or not it might actually need it.

the problem usually arises when upgrading databases with different character sets. that's...let fun.
in utf8, ascii character only take one byte, but the important thing is knowing the limitations of the character set you're choosing, and what the outcomes are.
 
As far as I know Nvarchar is UTF-16 and Varchar is UTF-8. It meaning Nvarchar support some special language like Chinese or Vietnamese. Is it right?
 
You must log in or register to reply here.

TRENDING THREADS

Back
Top