Вопрос: В чем разница между varchar и nvarchar?


Это просто nvarcharподдерживает многобайтовые символы? Если это так, существует ли какая-либо проблема, кроме проблем с хранением, использовать varchars?


1153


источник


Ответы:


nvarcharстолбец может хранить любые данные Unicode. varcharстолбец ограничен 8-разрядной кодовой страницей. Некоторые люди думают, что varcharдолжен использоваться, потому что он занимает меньше места. Я считаю, что это не правильный ответ. Codepage incompatabilities - это боль, а Unicode - это средство для проблем с кодировкой. В наши дни с дешевым диском и памятью, нет никаких оснований тратить время на списание кодовых страниц.

Все современные операционные системы и платформы разработки используют Unicode. Используя nvarcharскорее, чем varchar, вы можете избегать конверсий в кодировке каждый раз, когда вы читаете или записываете в базу данных. Конверсии требуют времени и подвержены ошибкам. И восстановление от ошибок преобразования является нетривиальной проблемой.

Если вы взаимодействуете с приложением, использующим только ASCII, я бы по-прежнему рекомендовал использовать Unicode в базе данных. Алгоритмы сопоставления ОС и базы данных будут работать лучше с Unicode. Unicode избегает проблем с конверсией при взаимодействии с Другие системы. И вы будете готовиться к будущему. И вы всегда можете подтвердить, что ваши данные ограничены 7-разрядным ASCII для любой прежней системы, которую вы должны поддерживать, даже наслаждаясь некоторыми преимуществами полного хранилища Unicode.


1424



VARCHAR : Именные данные переменной длины, не относящиеся к Юникоду. Сопоставление базы данных определяет, какая кодовая страница хранится в данных.

NVARCHAR : Символьные данные Unicode с переменной длиной. В зависимости от сопоставления базы данных для сравнения.

Вооружившись этими знаниями, используйте то, что соответствует вашим входным данным (ASCII v. Unicode).


223



Я всегда использую nvarchar, поскольку он позволяет все, что я создаю, выдерживать практически любые данные, которые я бросаю на него. Моя система CMS делает китайцы случайно, потому что я использовал nvarchar. В эти дни любые новые приложения не должны действительно касаться необходимого объема пространства.


61



Здесь вы можете увидеть различия между varcharа также nvarchar,

Enter image description here

Enter image description here

Enter image description here

Enter image description here

Справка: SqlHints.com

Для получения дополнительной информации о Nvarchar и varchar см. это сообщение в блоге ,


42



Это зависит от того, как Oracle был установлен. Во время процесса установки устанавливается опция NLS_CHARACTERSET. Вы можете найти его с запросом SELECT value$ FROM sys.props$ WHERE name = 'NLS_CHARACTERSET',

Если ваш NLS_CHARACTERSET является кодировкой Unicode, такой как UTF8, отлично. Использование VARCHAR и NVARCHAR в значительной степени идентичны. Прекратите читать сейчас, просто идите. В противном случае, или если у вас нет контроля над набором символов Oracle, читайте дальше.

VARCHAR. Данные хранятся в кодировке NLS_CHARACTERSET. Если на одном сервере есть другие экземпляры базы данных, вы можете быть ограничены ими; и наоборот, так как вам нужно поделиться настройкой. Такое поле может хранить любые данные, которые могут быть закодированы с использованием этого набора символов, и ничего больше , Например, если набор символов - MS-1252, вы можете хранить только такие символы, как английские буквы, несколько акцентированных букв и несколько других (например, и т.д.). Ваше приложение было бы полезно только для нескольких локалей, которые не могли работать нигде в мире. По этой причине считается «Плохой идеей».

NVARCHAR - данные хранятся в кодировке Unicode. Поддерживается каждый язык. Хорошая идея.

Как насчет пространства для хранения? VARCHAR обычно эффективен, поскольку набор символов / кодировка настраивается специально для конкретной локали. Поля NVARCHAR хранятся либо в кодировке UTF-8, либо в кодировке UTF-16, основываясь на настройке NLS, по иронии судьбы. UTF-8 очень эффективен для «западных» языков, поддерживая при этом азиатские языки. UTF-16 очень эффективен для азиатских языков, поддерживая при этом «западные» языки. Если речь идет о пространстве памяти, выберите параметр NLS, чтобы заставить Oracle использовать UTF-8 или UTF-16, если это необходимо.

Как насчет скорости обработки? Большинство новых платформ используют Unicode изначально (Java, .NET, даже C ++ std :: wstring из лет назад!), Поэтому, если поле базы данных является VARCHAR, оно заставляет Oracle конвертировать между наборами символов на каждое чтение или запись, что не очень хорошо. Использование NVARCHAR позволяет избежать преобразования.

Итог: используйте NVARCHAR! Он избегает ограничений и зависимостей, отлично подходит для хранения и обычно лучше подходит для производительности.


29



nvarchar хранит данные как Unicode, поэтому, если вы собираетесь хранить многоязычные данные (более одного языка) в столбце данных, вам нужен вариант N.


15



Мои два цента

  1. Индексы могут не работать, если не использовать правильные типы данных:
    В SQL Server: если у вас есть индекс над столбцом VARCHAR и представляет его строку Unicode, SQL Server не использует индекс. То же самое происходит, когда вы представляете BigInt в индексированный столбец, содержащий SmallInt. Даже если BigInt достаточно мал, чтобы быть SmallInt, SQL Server не может использовать индекс. У вас нет другой проблемы (при предоставлении SmallInt или Ansi-Code индексированного столбца BigInt от NVARCHAR).

  2. Типы данных могут различаться между различными СУБД (Data Management System):
    Знайте, что каждая база данных имеет несколько разные типы данных, а VARCHAR не означает, что везде. Хотя SQL Server имеет VARCHAR и NVARCHAR, база данных Apache / Derby имеет только VARCHAR и VARCHAR находится в Unicode.


13



Mainly nvarchar stores Unicode characters and varchar stores non-Unicode characters.

"Unicodes" means 16-bit character encoding scheme allowing characters from lots of other languages like Arabic, Hebrew, Chinese, Japanese, to be encoded in a single character set.

That means unicodes is using 2 bytes per character to store and nonunicodes uses only one byte per character to store. Which means unicodes need double capacity to store compared to non-unicodes.


11



You're right. nvarchar stores Unicode data while varchar stores single-byte character data. Other than storage differences (nvarchar requires twice the storage space as varchar), which you already mentioned, the main reason for preferring nvarchar over varchar would be internationalization (i.e. storing strings in other languages).


9



I would say, it depends.

If you develop a desktop application, where the OS works in Unicode (like all current Windows systems) and language does natively support Unicode (default strings are Unicode, like in Java or C#), then go nvarchar.

If you develop a web application, where strings come in as UTF-8, and language is PHP, which still does not support Unicode natively (in versions 5.x), then varchar will probably be a better choice.


8



If a single byte is used to store a character, there are 256 possible combinations, and thereby you can save 256 different characters. Collation is the pattern which defines the characters and the rules by which they are compared and sorted.

1252, which is the Latin1 (ANSI), is the most common. Single-byte character sets are also inadequate to store all the characters used by many languages. For example, some Asian languages have thousands of characters, so they must use two bytes per character.

Unicode standard

When systems using multiple code pages are used in a network, it becomes difficult to manage communication. To standardize things, the ISO and Unicode consortium introduced the Unicode. Unicode uses two bytes to store each character. That is 65,536 different characters can be defined, so almost all the characters can be covered with Unicode. If two computers use Unicode, every symbol will be represented in the same way and no conversion is needed - this is the idea behind Unicode.

SQL Server has two categories of character datatypes:

  • non-Unicode (char, varchar, and text)
  • Unicode (nchar, nvarchar, and ntext)

If we need to save character data from multiple countries, always use Unicode.


6