„NARODOWY” w tym przypadku oznacza postacie specyficzne dla różnych narodowości. Zwłaszcza języki dalekowschodnie mają tak wiele znaków, że jeden bajt to za mało miejsca, aby je wszystkie rozróżnić. Jeśli więc masz aplikację tylko w języku angielskim (ascii) lub pole tylko w języku angielskim , możesz uciec, używając starszych typów CHAR i VARCHAR, które zezwalają tylko na jeden bajt na znak.
To powiedziawszy, przez większość czasu powinieneś używać NCHAR / NVARCHAR. Nawet jeśli uważasz, że nie musisz obsługiwać (lub potencjalnie obsługiwać) wielu języków w swoich danych, nawet aplikacje tylko w języku angielskim muszą być w stanie rozsądnie radzić sobie z atakami bezpieczeństwa przy użyciu znaków obcojęzycznych.
Moim zdaniem jedynym miejscem, w którym nadal preferowane są starsze typy CHAR/VARCHAR, są często przywoływane wewnętrzne kody tylko w ascii i dane na platformach takich jak Sql Server, które obsługują rozróżnienie — dane, które byłyby odpowiednikiem enum w języku klienta, takim jak C++ lub C#.
