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

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

вопрос задан 27.09.2008
stimms
22535 репутация

18 ответов


  • 1454 рейтинг

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

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

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

    ответ дан Jeffrey L Whitledge, с репутацией 45271, 29.09.2008
  • 229 рейтинг

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

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

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

    ответ дан user7116, с репутацией 53721, 27.09.2008
  • 62 рейтинг

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

    ответ дан tags2k, с репутацией 27117, 27.09.2008
  • 41 рейтинг

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

    Enter image description here

    Enter image description here

    Enter image description here

    Enter image description here

    Ссылка: SqlHints. com

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

    ответ дан Arunprasanth K V, с репутацией 10836, 24.11.2014
  • 29 рейтинг

    Это зависит от того, как был установлен 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! Это позволяет избежать ограничений и зависимостей, отлично подходит для хранения данных и, как правило, лучше всего подходит для производительности.

    ответ дан Jeremy Frank, с репутацией 546, 7.10.2010
  • 16 рейтинг

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

    ответ дан albertein, с репутацией 19539, 27.09.2008
  • 13 рейтинг

    Мои два цента

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

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

    ответ дан incomudro, с репутацией 388, 19.04.2013
  • 11 рейтинг

    В основном nvarchar хранит символы Unicode и varchar хранит символы не Unicode.

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

    Это означает, что unicodes использует 2 байта на символ для хранения, а nonunicodes использует только один байт на символ для хранения. Это означает, что для хранения юникодов требуется двойная емкость по сравнению с не юникодом.

    ответ дан ranjit pawar, с репутацией 135, 14.12.2011
  • 9 рейтинг

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

    ответ дан Mike Spross, с репутацией 5916, 27.09.2008
  • 8 рейтинг

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

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

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

    ответ дан sleepy012, с репутацией 131, 25.01.2010
  • 6 рейтинг

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

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

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

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

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

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

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

    ответ дан Ali Elmi, с репутацией 181, 15.02.2016
  • 6 рейтинг

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

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

    Unicode стандарт

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

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

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

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

    ответ дан Jithin Shaji, с репутацией 3855, 4.06.2014
  • 6 рейтинг

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

    ответ дан Vijesh VP, с репутацией 2835, 27.09.2008
  • 5 рейтинг

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

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

    ответ дан Rafid, с репутацией 7248, 5.01.2017
  • 5 рейтинг

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

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

    ответ дан Pradeep Kesharwani, с репутацией 1397, 29.01.2014
  • 4 рейтинг

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

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

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

    • Проект или контекст
    • Инфраструктура
    • База данных системы
    ответ дан Paul, с репутацией 3229, 20.11.2013
  • 4 рейтинг

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

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

    1. Используется для хранения не-Unicode символов

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

    enter image description here

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

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

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

    1. Данные хранятся в кодировке Unicode. каждый язык поддерживается. (например, языки арабский, немецкий, хинди и т. д. и т. д.)
    ответ дан Debendra Dash, с репутацией 1916, 14.05.2017
  • 0 рейтинг

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

    ответ дан Rinoy Ashokan, с репутацией 307, 10.08.2017