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

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

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

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

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

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

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

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

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

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

Мои два цента

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 находится в Unicode.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Стандарт Юникода

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

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

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

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

Я должен сказать здесь (я понимаю, что, вероятно, собираюсь открыть себя для рекламы!), Но, безусловно, это единственный раз, когда NVARCHAR действительно более полезен (обратите внимание на more < / em> там!) чем VARCHAR, когда все параметры сортировки во всех зависимых системах и в самой базе данных одинаковы ...? В противном случае преобразование сопоставления должно произойти в любом случае, что делает VARCHAR столь же жизнеспособным, как NVARCHAR.