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

Ответ 1

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

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

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

Ответ 2

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

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

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

Ответ 3

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

Ответ 4

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

Ссылка: SqlHints.com

Подробнее о Nvarchar и varchar см. этот пост в блоге.

Ответ 5

Это зависит от того, как был установлен 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, даже С++ std:: wstring из лет назад!), Поэтому, если поле базы данных является VARCHAR, оно заставляет Oracle конвертировать между наборами символов на каждое чтение или запись, что не очень хорошо. Использование NVARCHAR позволяет избежать преобразования.

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

Ответ 6

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

Ответ 7

Мои два цента

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

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

Ответ 8

В основном nvarchar хранит символы Unicode и varchar хранит символы, отличные от Юникода.

"Юникоды" означает 16-битную схему кодирования символов, позволяющую кодировать символы из множества других языков, таких как арабский, иврит, китайский, японский, в одном наборе символов.

Это означает, что юникоды используют 2 байта на символ для хранения, а не-unicode использует только один байт на символ для хранения. Это означает, что юникоды нуждаются в двойной емкости для хранения по сравнению с не-Юникодами.

Ответ 9

Ты прав. nvarchar хранит данные Unicode, а varchar хранит однобайтовые символьные данные. Помимо различий в памяти (nvarchar требуется вдвое больше места для хранения как varchar), то, что вы уже упоминали, основной причиной предпочтения nvarchar over varchar будет интернационализация (т.е. сохранение строк на других языках).

Ответ 10

Я бы сказал, это зависит.

Если вы разрабатываете настольное приложение, где ОС работает в Unicode (как и все текущие системы Windows), а язык поддерживает Unicode (строки по умолчанию - Unicode, например, на Java или С#), перейдите в nvarchar.

Если вы разрабатываете веб-приложение, где строки входят как UTF-8, а язык - это PHP, который по-прежнему не поддерживает Unicode изначально (в версиях 5.x), то, вероятно, лучшим вариантом будет varchar.

Ответ 11

nVarchar поможет вам сохранить символы Unicode. Это путь, если вы хотите хранить локализованные данные.

Ответ 12

Если для хранения символа используется один байт, существует 256 возможных комбинаций, и вы можете сохранить 256 разных символов. Collation - это шаблон, который определяет символы и правила, по которым они сравниваются и сортируются.

1252, который является Latin1 (ANSI), является наиболее распространенным. Однобайтовые наборы символов также неадекватны для хранения всех символов, используемых многими языками. Например, некоторые азиатские языки имеют тысячи символов, поэтому они должны использовать два байта на символ.

Стандарт Unicode

Когда системы, использующие несколько кодовых страниц, используются в сети, становится сложно управлять связью. Чтобы стандартизировать ситуацию, консорциум ISO и Unicode представил Unicode. Unicode использует два байта для хранения каждого символа. Это может быть определено 65 536 разных символов, поэтому почти все символы могут быть покрыты Unicode. Если два компьютера используют Unicode, каждый символ будет представлен таким же образом, и преобразование не требуется - это идея Unicode.

SQL Server имеет две категории типов символов:

• не-Unicode (char, varchar и текст)
• Юникод (nchar, nvarchar и ntext)

Если нам нужно сохранить символьные данные из разных стран, всегда используйте Unicode.

Ответ 13

Несмотря на то, что NVARCHAR хранит Юникод, вы также можете рассмотреть с помощью сопоставления, вы можете использовать VARCHAR и сохранить свои данные на своих локальных языках.

Представьте себе следующий сценарий.

Сравнение вашей БД является персидским, и вы сохраняете значение типа "علی" (персидское письмо Али) в типе VARCHAR(10). Нет проблем, и СУБД использует только три байта для их хранения.

Однако, если вы хотите перенести свои данные в другую базу данных и увидеть правильный результат, ваша целевая база данных должна иметь тот же набор, что и целевой, который является персидским в этом примере.

Если ваша целевая сопоставление отличается, вы видите в целевой базе данных вопросительные знаки (?).

Наконец, помните, если вы используете огромную базу данных, которая предназначена для использования вашего локального языка, я бы рекомендовал использовать местоположение вместо использования слишком большого количества пробелов.

Я считаю, что дизайн может быть другим. Это зависит от среды, в которой вы работаете.

Ответ 14

Я должен сказать здесь (я понимаю, что я, вероятно, собираюсь раскрыться перед планкой!), Но, безусловно, единственный раз, когда NVARCHAR на самом деле более полезен (заметьте, чем больше!), Чем VARCHAR, когда все сопоставления на всех зависимых системах и внутри самой базы данных одинаковы...? Если нет, то преобразование в любом случае должно произойти, и VARCHAR становится таким же жизнеспособным, как NVARCHAR.

Чтобы добавить к этому, некоторые системы баз данных, такие как SQL Server (до 2012 года), имеют размер страницы ок. 8K. Итак, если вы хотите хранить данные для поиска, которые не хранятся в чем-то вроде поля TEXT или NTEXT тогда VARCHAR обеспечивает полное пространство 8 NVARCHAR тогда как NVARCHAR обеспечивает только 4 NVARCHAR (удваивает байты, удваивает пространство).

Я предполагаю, что в итоге использование любого из них зависит от:

• Проект или контекст
• инфраструктура
• Система баз данных

Ответ 15

Следуйте Разница между Sql-сервером VARCHAR и типом данных NVARCHAR. Здесь вы можете увидеть очень описательный способ.

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

Ответ 16

Я просмотрел ответы, и многие, кажется, рекомендуют использовать nvarchar over varchar, потому что пространство больше не проблема, поэтому нет вреда в том, что Unicode позволяет немного увеличить объем хранилища. Ну, это не всегда так, когда вы хотите применить индекс к столбцу. SQL Server имеет ограничение в 900 байт по размеру поля, которое вы можете индексировать. Поэтому, если у вас есть varchar(900), вы можете его индексировать, но не varchar(901). С nvarchar количество символов сокращается наполовину, поэтому вы можете индексировать до nvarchar(450). Поэтому, если вы уверены, что вам не нужен nvarchar, я не рекомендую его использовать.

В целом, в базах данных я рекомендую придерживаться требуемого размера, потому что вы всегда можете расширять. Например, коллега на работе однажды подумал, что нет никакого вреда в использовании nvarchar(max) для столбца, так как у нас нет проблем с хранением вообще. Позже, когда мы попытались применить индекс к этому столбцу, SQL Server отклонил это. Если, однако, он начал с даже varchar(5), мы могли бы просто расширить его позже до того, что нам нужно без такой проблемы, что потребует от нас сделать план миграции на местах для устранения этой проблемы.

Ответ 17

Основное различие между Varchar(n) и nvarchar(n):

Varchar (переменные длины, не-Unicode символьные данные) размером до 8000.  1. Это тип данных переменной длины

2. Используется для хранения символов, отличных от Юникода

3. Занимает 1 байт пробела для каждого символа

Nvarchar: символьные данные Unicode с переменной длиной.

1. Это тип данных переменной длины

2.Используется для хранения символов Юникода.

3. Данные хранятся в кодировке Unicode. каждый поддерживается язык. (например, языки арабский, немецкий, хинди и т.д. и т.д.).

Ответ 18

nvarchar безопасен в использовании по сравнению с varchar для того, чтобы сделать наш код без ошибок (несоответствие типов), потому что nvarchar допускает символы юникода. Когда мы используем условие where в запросе SQL Server и если мы используем оператор =, это несколько раз выдаст ошибку. Вероятная причина этого заключается в том, что наша картографическая колонка будет различаться в varchar. Если мы определили это в nvarchar этой проблемы не может быть. Тем не менее мы придерживаемся varchar и избегаем этой проблемы, поэтому лучше использовать ключевое слово LIKE а не =.

Ответ 19

Джеффри Л Уитледж с оценкой репутации ~ 47000 рекомендует использовать nvarchar

Соломон Руцки с оценкой репутации ~ 33200 рекомендует: НЕ всегда использовать NVARCHAR. Это очень опасный и часто дорогостоящий подход/подход.

Каковы основные различия в производительности между типами данных SQL Server varchar и nvarchar?

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

Оба человека с такой высокой репутацией, что выбирает обучающийся разработчик базы данных SQL Server?

В ответах и комментариях есть много предупреждений о проблемах производительности, если вы не согласны с выбором.

Есть комментарии pro/con nvarchar для производительности.

Есть комментарии pro/con varchar для производительности.

У меня есть особые требования к таблице со многими сотнями столбцов, что само по себе, вероятно, необычно?

Я выбираю varchar, чтобы не приближаться к пределу размера записи таблицы в 8060 байт в SQL * server 2012.

Использование nvarchar для меня превышает ограничение в 8060 байт.

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

Я видел использование столбца varchar на этом рабочем месте, правительство Южной Австралии, предыдущими опытными разработчиками баз данных, где число строк таблицы будет составлять несколько миллионов или более (и очень мало столбцов nvarchar, если таковые имеются, в этих очень больших таблицы), поэтому, возможно, ожидаемые объемы строк данных становятся частью этого решения.

Ответ 20

nvarchar хранит данные Unicode, а varchar хранит данные ASCII. Они работают одинаково, но nvarchar занимает в два раза больше места.