Powinieneś używać NVARCHAR za każdym razem, gdy musisz przechowywać wiele języków. Wierzę, że musisz użyć go do języków azjatyckich, ale nie Cytuj mnie na nim.

Oto problem, jeśli weźmiesz na przykład rosyjski i przechowasz go w warcharze, będzie dobrze, o ile zdefiniujesz poprawną stronę kodu. Ale powiedzmy, że używasz domyślnej Angielskiej instalacji sql, wtedy rosyjskie znaki nie będą obsługiwane poprawnie. Jeśli używasz nvarchar (), będą obsługiwane jak należy.

Edytuj

Ok pozwól, że zacytuję MSDN i może byłem konkretny, ale nie chcesz przechowywać więcej niż jednej strony kodowej w kolumnie varcar, podczas gdy możesz nie powinieneś

Gdy masz do czynienia z danymi tekstowymi, które są przechowywany w char, varchar, varchar (max), czyli tekstowy typ danych, najważniejsze ograniczenie do rozważenia czy to tylko informacja z jednego stronę kodową można zweryfikować za pomocą system. (Możesz przechowywać dane z wiele stron kodowych, ale to nie jest polecam.) Dokładna strona kodowa użyta walidacji i przechowywania danych zależy w sprawie zestawienia kolumny. Jeśli a zestawienie na poziomie kolumny nie zostało zdefiniowany, zestawianie bazy danych jest używany. Aby określić stronę kodową który jest używany dla danej kolumny, ty można użyć COLLATIONPROPERTY funkcja, jak pokazano poniżej przykłady kodu:

Oto jeszcze:

Ten przykład ilustruje fakt, że wiele miejsc, takich jak Gruziński i Hindi, nie mają stron kodowych, ponieważ są kolacjami tylko Unicode. Te zestawienia nie są odpowiednie dla kolumny, które używają znaku, varchar lub typ danych tekstowych

Więc gruziński lub Hindi naprawdę muszą być przechowywane jako nvarchar. Arabski też jest problemem:

Innym problemem, który możesz napotkać, jest niemożność przechowywania danych, gdy nie wszystkie postacie, które chcesz wsparcie zawarte jest w kodzie strona. W wielu przypadkach okna rozważa konkretnej strony kodowej, aby być " najlepszym fit " strona kodowa, czyli jest brak gwarancji, że możesz polegać na strona kodowa do obsługi całego tekstu; jest tylko najlepszy dostępny. Na przykładem tego jest skrypt arabski: obsługuje szeroką gamę języków, w tym Baluchi, Berber, Farsi, Kaszmirski, Kazachski, Kirgiski, Paszto, Sindhi, Ujgur, Urdu i inne. Wszystkie języki te mają dodatkowe znaki poza tymi po arabsku język określony w Kod Windows strona 1256. W przypadku próby przechowywania te Dodatkowe znaki w kolumna non-Unicode, która ma Arabski zestawienie, znaki są zamienione na znaki zapytania.

Coś, o czym należy pamiętać, gdy używasz Unicode chociaż możesz przechowywać różne języki w jednej kolumnie, możesz sortować tylko za pomocą jednego zestawienia. Istnieją języki, które używają znaków łacińskich, ale nie są podobne do innych języków łacińskich. Akcent jest tego dobrym przykładem, I nie mogę zapamiętać przykładu, ale był Wschodnioeuropejski język, którego Y nie sortowało jak angielski Y. następnie jest Hiszpański ch, który hiszpańscy użytkownicy expet być sortowane po h.

W sumie ze wszystkimi problemami, z którymi musisz się uporać, gdy masz do czynienia z internalizacją. Moim zdaniem łatwiej jest po prostu używać znaków Unicode od samego początku, unikać dodatkowych konwersji i wziąć hit spacji. Stąd moje wcześniejsze oświadczenie.

Grek potrzebowałby UTF-8 na N typach kolumn: αβγ;)

Josh says: "....Coś, o czym należy pamiętać, gdy używasz Unicode chociaż możesz przechowywać różne języki w jednej kolumnie, możesz sortować tylko za pomocą jednego zestawienia. Istnieją języki, które używają znaków łacińskich, ale nie są podobne do innych języków łacińskich. Akcenty jest dobrym przykładem tego, nie mogę zapamiętać przykładu, ale był język Wschodnioeuropejski, którego Y nie sortował jak angielski Y. następnie jest Hiszpański ch, który hiszpańscy użytkownicy expet być sortowane po h. "

Jestem native speakerem języka hiszpańskiego i " ch "nie jest literą, ale dwoma" c " i "h", a alfabet hiszpański jest jak: abcdefghijklmn opqrstuvwxyz Nie oczekujemy "ch" po "h", ale " i" Alfabet jest taki sam jak w języku angielskim z wyjątkiem ñ lub w HTML "& ntilde; "

Alex

TL; DR;
Unicode - (nchar, nvarchar i ntext)
Non-unicode - (char, varchar i text).

Z MSDN

Kolacje w SQL Server zapewniają reguły sortowania, wielkość liter i akcent właściwości wrażliwości danych. Kolacje, które są używane z typy danych znaków, takie jak char i varchar, dyktują stronę kodową i odpowiednie znaki, które mogą być reprezentowane dla tych danych Typ.

Zakładając, że używasz domyślne zestawienie SQL SQL_Latin1_General_CP1_CI_AS następnie następujący skrypt powinien wydrukować wszystkie symbole, które można zmieścić VARCHAR, ponieważ używa jednego bajtu do przechowywania jednego znaku (łącznie 256), jeśli nie widzisz go na wydrukowanej liście-potrzebujesz NVARCHAR.

declare @i int = 0;
while (@i < 256)
begin
print cast(@i as varchar(3)) + '  '+  char(@i)  collate SQL_Latin1_General_CP1_CI_AS 
print cast(@i as varchar(3)) + '  '+ char(@i)  collate Japanese_90_CI_AS  
set @i = @i+1;
end

Jeśli zmienisz zestawienie na lets say japanese zauważysz, że wszystkie dziwne litery Europejskie zamieniły się w normalne, a niektóre symbole w znaki ?.

Unicode jest standardem mapowania punktów kodu na znaki. Ponieważ on zaprojektowany, aby objąć wszystkie znaki wszystkich języków świata, nie ma potrzeby, aby różne strony kodowe obsługiwały różne zestawy znaków. Jeśli przechowujesz dane znaków, które odzwierciedlają wiele języki, zawsze używaj typów danych Unicode (nchar, nvarchar i ntext) zamiast typów danych innych niż Unicode (char, varchar i text).

Inaczej Twoje sortowanie będzie dziwne.