This only depends on your requirements.
Use them, when you need them. Don't use it, when you don't need them.
When it's not specified, review your requierments. And clear this point.
It's not that clear. There are no requirements regarding this. We are small shop and the requirements are "build an application for this".
I've noticed them being used in a couple modern databases and in a create database script created by SSMS today. My impression from this is that the Unicode types are very common in newly created(modern) databases. I don't know if I should use them in all new applications I create that don't have to deal with other types of encoding though.
Maybe, but we have no specs or business rules.
Did you know that Unicode requires that the "bottom of ASCII" has to be part of all the languages that are supported? This is the basic Latin alphabet, digits and some simple punctuation marks. This is so that any encoding in ISO Standards can port.
The Unicode types are to support languages and characters other than English. Does your application need to support languages other than English?
Like everyone else already mentioned it depends. If you have no requirements then look at each column as you are creating it and ask yourself what type of data it will contain.
Personally I use unicode (nvarchar) when data will contain names of people, names of places, translated texts outside of English, etc. Even if your application resides inside a small company in an English speaking country (like the USA for example) people could use the application that have names that can not be mapped to ASCII letters and if you record these names in your application's database then you should be using NVarchar.
I use ASCII (varchar) when data will never contain non-ascii characters like proper URLs (that are not mapped), program specific codes, email addresses (again, not mapped), and other data that I know will always be ASCII format.
Basically, if you require unicode characters in your data, you should use NVARCHAR. If you do not, use VARCHAR.
If you don't know, your options are to play it safe, and allow for it, or to explicitly forbid it from the get go.
If you try to put a unicode character in a ascii field, you'll wind up with a ?.
Following on from Igors example, there are lots of instances outside of English where UNICODE characters come into play. ASCII is sufficient to represent most western names. But as soon as you start to move into the non-english alphabets, you run into trouble:
SELECT CAST(N'Vaqif Smdolu' AS NVARCHAR), CAST('Vaqif Smdolu' AS VARCHAR)
But we don't do business in other countries! Yeah.. but people from those countries don't stay there. They may be in your country, wanting to give you their money! Vaqif wants to be your customer, but only if your can respect his culture, and print his name properly!
As others have said, it depends. If the system will only work in your home country, varchar will suffice.
However, there is one thing to keep in mind. What could happen in the future? The system I work with uses varchar, and we have damned good excuse for this: the system was born before SQL Server had Unicode support. Our system runs/has run in Sweden, Finland, Norway, Denmark, Germany and Luxemburg. As code page 1252 works for all of these, no problem. But a couple of years ago, one of our customers was looking into expanding into the Polish market, and for Polish, varchar with code page 1252 won't do. And the customer wanted to have the Polish customers in the same database.
Converting the database to use nvarchar after the fact is not cheap, and for various reason (not only because of the database), the Polish venture was cancelled.
But that is the morale: if you use nvarchar, supporting a multi-lingual environment in the future will be a lot easier.
This topic is archived. No further replies will be accepted.
Other recent topics
