Jaka jest różnica między varchar i nvarchar?

Varchar: Dane znaków o zmiennej długości, inne niż Unicode. Zestawienie bazy danych określa, z której strony kodowej są przechowywane dane.

Nvarchar: Dane znaków Unicode o zmiennej długości. Zależny od zestawienia bazy danych w celu porównania.

Uzbrojony w tę wiedzę, użyj tego, który pasuje do Twoich danych wejściowych (ASCII V. Unicode).

Zawsze używam nvarchar, ponieważ pozwala to cokolwiek buduję, aby wytrzymać prawie wszystkie dane, które rzucam na niego. Mój system CMS robi Chiński przez przypadek, ponieważ używałem nvarchar. W dzisiejszych czasach wszelkie nowe aplikacje nie powinny tak naprawdę martwić się o ilość wymaganej przestrzeni.

To zależy od tego, jak Oracle został zainstalowany. Podczas procesu instalacji ustawiana jest opcja NLS_CHARACTERSET. Możesz go znaleźć za pomocą zapytania SELECT value$ FROM sys.props$ WHERE name = 'NLS_CHARACTERSET'.

Jeśli twój NLS_CHARACTERSET jest kodowaniem Unicode, takim jak UTF8, świetnie. Używanie VARCHAR i NVARCHAR są prawie identyczne. Przestań czytać, po prostu zrób to. W przeciwnym razie lub jeśli nie masz kontroli nad zestawem znaków Oracle, Czytaj dalej.

VARCHAR-dane są przechowywane w kodowaniu NLS_CHARACTERSET. Jeśli są inne instancje bazy danych na tym samym serwerze, mogą być ograniczone przez nich; i odwrotnie, ponieważ trzeba udostępnić ustawienie. takie pole może przechowywać dowolne dane, które mogą być zakodowane za pomocą tego zestawu znaków, i nic więcej. Na przykład, jeśli zestaw znaków to MS-1252, można przechowywać tylko znaki, takie jak angielskie litery, garść akcentowanych liter i kilka innych (takich jak € i -). Twoja aplikacja byłaby przydatna tylko w kilku lokalizacjach, nie mogąc działać w żadnym innym miejscu na świecie. Na z tego powodu jest uważany za zły pomysł.

NVARCHAR-dane są przechowywane w kodowaniu Unicode. Każdy język jest obsługiwany. Dobry Pomysł.

A co z miejscem do przechowywania? VARCHAR jest ogólnie wydajny, ponieważ zestaw znaków / kodowanie zostało zaprojektowane specjalnie dla określonych ustawień regionalnych. Pola NVARCHAR przechowują się w kodowaniu UTF-8 lub UTF-16, bazując na Ustawieniach NLS. UTF-8 jest bardzo wydajny dla języków "zachodnich", jednocześnie wspierając języki azjatyckie. UTF-16 jest bardzo wydajny dla języków azjatyckich, przy jednoczesnym wspieraniu języków "zachodnich". Jeśli chodzi o przestrzeń dyskową, wybierz ustawienie NLS, aby Oracle używało odpowiednio UTF-8 lub UTF-16.

Podsumowując: użyj NVARCHAR! Unika ograniczeń i zależności, jest odpowiedni dla przestrzeni dyskowej i zwykle najlepszy dla wydajności.

Nvarchar przechowuje dane jako Unicode, więc jeśli zamierzasz przechowywać dane wielojęzyczne (więcej niż jeden język)w kolumnie danych, potrzebujesz wariantu N.

Moje dwa grosze

1. Indeksy mogą zawieść, gdy nie są używane poprawne typy danych:
   W SQL Server: gdy masz indeks nad kolumną VARCHAR i przedstawiasz mu ciąg znaków Unicode, SQL Server nie korzysta z indeksu. To samo dzieje się, gdy prezentujesz BigInt do zindeksowanej kolumny zawierającej SmallInt. Nawet jeśli BigInt jest wystarczająco mały, aby być SmallInt, SQL Server nie jest w stanie użyć indeksu. Na odwrót nie masz tego problemu (przy podawaniu SmallInt lub ANSI-kod do zindeksowanej kolumny BigInt ot NVARCHAR).

2. Typy danych mogą się różnić w zależności od DBMS (System zarządzania Bazą Danych):
   Wiedz, że każda baza danych ma nieco inne typy danych, a VARCHAR nie wszędzie oznacza to samo. Podczas gdy SQL Server ma VARCHAR i NVARCHAR, baza danych Apache/Derby ma tylko VARCHAR, a VARCHAR jest w Unicode.

Głównie nvarchar przechowuje znaki Unicode, a varchar przechowuje znaki inne niż Unicode.

"Unicodes" oznacza 16-bitowy schemat kodowania znaków pozwalający na kodowanie znaków z wielu innych języków, takich jak arabski, hebrajski, chiński, japoński, w jednym zestawie znaków.

Oznacza to, że unicodes używa 2 bajtów na znak do przechowywania, a nonunicodes używa tylko jednego bajtu na znak do przechowywania. Co oznacza, że unicody potrzebują podwójnej pojemności do przechowywania w porównaniu do nie-unicodes.

Masz rację. nvarchar przechowuje dane Unicode, podczas gdy varchar przechowuje dane znaków jednobajtowych. Poza różnicami w przechowywaniu (nvarchar wymaga dwukrotnie większej przestrzeni niż varchar), o czym już wspomniałeś, głównym powodem preferowania nvarchar nad varchar byłaby Internacjonalizacja (tzn. przechowywanie łańcuchów w innych językach).

Powiedziałbym, że to zależy.

Jeśli tworzysz aplikację desktopową, w której System Operacyjny Działa w Unicode (jak wszystkie obecne systemy Windows), a język natywnie obsługuje Unicode( domyślne ciągi znaków to Unicode, jak w Javie lub C#), przejdź do nvarchar.

Jeśli tworzysz aplikację internetową, w której ciągi znaków występują jako UTF-8, a językiem jest PHP, który nadal nie obsługuje natywnie Unicode (w wersjach 5.x), wtedy varchar będzie prawdopodobnie lepszym wyborem.

Chociaż NVARCHAR przechowuje Unicode, powinieneś rozważyć przy pomocy collation również możesz użyć VARCHAR i zapisać swoje dane z lokalnych języków.

Zestawianie twojego DB jest perskie i zapisujesz wartość taką jak' علی ' (perski zapis Ali) w typie danych VARCHAR(10). Nie ma problemu i DBMS używa tylko trzech bajtów do przechowywania go.

Jeśli jednak chcesz przenieść swoje dane do innej bazy danych i zobaczyć poprawny wynik twoja docelowa baza danych musi mieć takie samo zestawienie jak cel, który jest perski w tym przykładzie.

Jeśli twój cel jest inny, widzisz kilka znaków zapytania(?) w docelowej bazie danych.

Na koniec pamiętaj, jeśli używasz ogromnej bazy danych, która służy do używania lokalnego języka, zalecałbym Użycie lokalizacji zamiast używania zbyt wielu spacji.

Wierzę, że projekt może być inny. To zależy od środowiska, w którym pracujesz.

NVarchar pomoże Ci przechowywać znaki Unicode. Jest to sposób, aby przejść, jeśli chcesz przechowywać zlokalizowane dane.

Spojrzałem na odpowiedzi i wielu wydaje się zalecać użycie nvarchar nad varchar, ponieważ przestrzeń nie jest już problemem, więc nie ma nic złego w włączeniu Unicode dla małej dodatkowej pamięci. Cóż, nie zawsze jest to prawdą, gdy chcesz zastosować indeks nad kolumną. SQL Server ma limit 900 bajtów rozmiaru pola, które możesz indeksować. Więc jeśli masz varchar(900), możesz go indeksować, ale nie varchar(901). Z nvarchar liczba znaków jest zmniejszona o połowę, więc możesz indeksować do nvarchar(450). Więc jeśli są pewni, że nie potrzebujesz nvarchar, nie polecam go używać.

Ogólnie w bazach danych zalecam trzymanie się potrzebnego rozmiaru, ponieważ zawsze można rozszerzyć. Na przykład kolega z pracy pomyślał kiedyś, że nie ma nic złego w użyciu nvarchar(max) dla kolumny, ponieważ nie mamy żadnego problemu z przechowywaniem. Później, gdy próbowaliśmy zastosować indeks nad tą kolumną, SQL Server odrzucił to. Gdyby jednak zaczął od even varchar(5), moglibyśmy po prostu rozszerzyć go później do tego, czego potrzebujemy bez takiego problemu, który będzie wymagał od nas zrobienia planu migracji w terenie, aby rozwiązać ten problem.

Jeśli do przechowywania znaku używany jest pojedynczy bajt, istnieje 256 możliwych kombinacji, dzięki czemu można zapisać 256 różnych znaków. Collation to wzorzec, który definiuje znaki i reguły, według których są one porównywane i sortowane.

1252, czyli Latin1 (ANSI), jest najczęściej Jednobajtowe zestawy znaków są również niewystarczające do przechowywania wszystkich znaków używanych przez wiele języków. Na przykład niektóre języki azjatyckie mają tysiące znaków, więc muszą używać dwóch bajtów na znak.

Standard Unicode

Gdy systemy wykorzystujące wiele stron kodowych są używane w sieci, Zarządzanie komunikacją staje się trudne. Aby ujednolicić rzeczy, konsorcjum ISO i Unicode wprowadziło Unicode . Unicode używa dwóch bajtów do przechowywania każdego znaku. To jest 65,536 różne znaki mogą być zdefiniowane, więc prawie wszystkie znaki mogą być pokryte Unicode. Jeśli dwa komputery używają Unicode, każdy symbol będzie reprezentowany w ten sam sposób i nie konwersja jest potrzebna - taka jest idea Unicode.

SQL Server ma dwie kategorie danych znakowych:

Nie-Unicode (char, varchar i text) W tym celu należy wykonać następujące czynności:]}

Jeśli musimy zapisać dane znaków z wielu krajów, Zawsze używaj Unicode.

Główna różnica między Varchar(n) i nvarchar(n) jest:

Varchar( zmienna długość, non-Unicode dane znaków) rozmiar jest do 8000. 1.It jest typem danych o zmiennej długości

1. Używane do przechowywania znaków innych niż Unicode

2. Zajmuje 1 bajt przestrzeni dla każdego znaku

Nvarchar:Dane znaków Unicode o zmiennej długości.

1.It jest typem danych o zmiennej długości

2.Używany do przechowywania Unicode postaci.

1. dane są przechowywane w kodowaniu Unicode. Każdy język jest obsługiwany. (na przykład języki arabski, niemiecki, Hindi itp.)

Muszę powiedzieć tutaj (zdaję sobie sprawę, że prawdopodobnie otworzę się na slating!), ale z pewnością jedyny raz, kiedy NVARCHAR jest rzeczywiście bardziej użyteczny (zwróć uwagę na więcej tam!) niż VARCHAR jest wtedy, gdy wszystkie zestawienia we wszystkich systemach zależnych i w samej bazie danych są takie same...? Jeśli nie, to konwersja musi nastąpić i tak, a więc sprawia, że VARCHAR jest tak samo realna jak NVARCHAR.

Aby dodać do tego niektóre systemy bazodanowe, takie jak SQL Server (przed 2012) mają rozmiar strony OK. 8K. jeśli więc chodzi o przechowywanie przeszukiwalnych danych, które nie są przechowywane w polu TEXT lub NTEXT, to VARCHAR zapewnia pełną wartość 8K przestrzeni, podczas gdy NVARCHAR zapewnia tylko 4k (dwukrotnie bajty, dwukrotnie przestrzeń).

Przypuszczam, że podsumowując, użycie obu zależy od:

• projekt lub kontekst
• infrastruktura
• system baz danych

Follow Różnica między typem danych Sql Server VARCHAR a nvarchar. Tutaj można zobaczyć w bardzo opisowy sposób.

W ogólnościnvarchar przechowuje dane jako Unicode, więc jeśli zamierzasz przechowywać dane wielojęzyczne (więcej niż jeden język)w kolumnie danych, potrzebujesz wariantu N.

Jeffrey L Whitledge z ~ 47000 reputation score zaleca użycie nvarchar

Solomon Rutzky z ~ 33200 reputation score zaleca: nie zawsze używaj NVARCHAR. Jest to bardzo niebezpieczne i często kosztowne podejście.

Jakie są główne różnice wydajności między typami danych varchar i nvarchar SQL Server?

Https://www.sqlservercentral.com/articles/disk-is-cheap-orly-4

Obie osoby o tak wysokim reputacja, co wybiera programista baz danych SQL server?

Istnieje wiele ostrzeżeń w odpowiedziach i komentarzach dotyczących problemów z wydajnością, jeśli nie jesteś konsekwentny w wyborach.

Są komentarze pro / con nvarchar dla wydajności.

Są komentarze pro / con varchar dla wydajności.

Mam szczególny wymóg dla tabeli z wieloma setkami kolumn, co samo w sobie jest chyba nietypowe ?

Wybieram varchar, aby uniknąć zbliżania się do limitu rozmiaru rekordu tabeli 8060 bajtów w SQL * server 2012.

Użycie nvarchar, dla mnie, przekracza limit 8060 bajtów.

Myślę również, że powinienem dopasować typy danych powiązanych tabel kodu do typów danych głównej tabeli centralnej.

Widziałem użycie kolumny varchar w tym miejscu pracy, w rządzie Australii Południowej, przez poprzednich doświadczonych programistów baz danych, gdzie liczba wierszy tabeli będzie wynosić kilka milionów lub więcej (i bardzo niewiele nvarchar kolumny, jeśli istnieją, w tych bardzo dużych tabelach), więc być może oczekiwane woluminy wierszy danych staną się częścią tej decyzji.

Od SQL Server 2019 kolumny varchar obsługują kodowanie UTF-8.

Stąd od teraz różnica jest wielkością.

W systemie bazodanowym, który przekłada się na różnicę prędkości.

Mniejszy rozmiar = mniej IO + mniej pamięci = ogólnie większa prędkość. Przeczytaj artykuł powyżej dla liczb.

Go for varchar in UTF8 from now on!

Tylko jeśli masz duży procent danych ze znakami w zakresach 2048 - 16383 i 16384 – 65535 - you będzie musiał zmierzyć

nvarchar jest bezpieczny w użyciu w porównaniu do varchar, aby nasz kod był wolny od błędów (wpisz niedopasowanie), ponieważ nvarchar pozwala również na znaki unicode. Gdy użyjemy warunku where w zapytaniu SQL Server i jeśli użyjemy operatora =, spowoduje to wyświetlenie błędu kilka razy. Prawdopodobnym powodem tego jest to, że nasza kolumna mapowania będzie zróżnicowana w varchar. Jeśli zdefiniujemy to w {[0] } ten problem nie zdarzy się. Nadal trzymamy się varchar i unikamy tego problemu lepiej używać LIKE słowa kluczowego zamiast =.