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

Question

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

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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

Answer 4

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

Answer 5

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

Answer 6

Мои два цента

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

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

Answer 7

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

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

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

Answer 8

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

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

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

Answer 9

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

Answer 10

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