nVarChar vs VarChar

[TechBoyJK]

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.

 

[Crusty]

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.

 

[TechBoyJK]

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.

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.

 

[nickbits]

I've been using nvarchar exclusively for years.

 

[Bulldog13]

I've been using nvarchar exclusively for years.

same here

 

[ForumMaster]

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.

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".

 

[Crusty]

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".

I cringe every time I see a mysql database with 'latin1_swidesh_ci' as the character set. D:

 

[Markbnj]

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.

 

[ForumMaster]

I cringe every time I see a mysql database with 'latin1_swidesh_ci' as the character set. D:

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.

 

[clamum]

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.

Seconded.

 

[TechBoyJK]

Seconded.

Thirded.> I started the thread and after reading the replies and considering everything, this is the approach I am going to adopt.

 

[patticrook33]

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?