Prawdziwym powodem, dla którego chcesz używać NVARCHAR, jest to, że masz inne języki w tej samej kolumnie, musisz zaadresować kolumny w T-SQL bez dekodowania, chcesz widzieć dane "natywnie" w SSMS lub chcesz ujednolicić Unicode.
Jeśli traktujesz bazę danych jako pamięć głupa, jest całkowicie możliwe przechowywanie szerokich ciągów i różnych (nawet o zmiennej długości) kodowania w VARCHAR (na przykład UTF-8). Problem pojawia się, gdy próbujesz kodować i dekodować, zwłaszcza jeśli strona kodowa jest inna dla różnych wierszy. Oznacza to również, że SQL Server nie będzie w stanie łatwo poradzić sobie z danymi w celu wykonywania zapytań w T-SQL o (potencjalnie zmiennie) zakodowanych kolumnach.
Korzystanie z NVARCHAR pozwala uniknąć tego wszystkiego.
Polecam NVARCHAR dla każdej kolumny, która będzie zawierała dane wprowadzone przez użytkownika, co jest stosunkowo nieograniczone.
Poleciłbym VARCHAR dla każdej kolumny, która jest naturalnym kluczem (takim jak tablica rejestracyjna pojazdu, numer SSN, numer seryjny, numer seryjny, numer zamówienia, znak wywoławczy lotniska itp.), która jest zwykle zdefiniowana i ograniczona przez normę, ustawodawstwo lub konwencję. Również VARCHAR dla wprowadzonych przez użytkownika i bardzo ograniczonych (takich jak numer telefonu) lub kod (AKTYWNY/ZAMKNIĘTY, T/N, M/F, M/S/D/W, itp.). Nie ma absolutnie żadnego powodu, aby używać do nich NVARCHAR.
A więc prosta zasada:
VARCHAR, gdy gwarantowane jest ograniczenieNVARCHAR w przeciwnym razie
