В чем разница между varchar и nvarchar?
https://stackoverflow.com/questions/144283
-
02-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Это просто nvarchar поддерживает многобайтовые символы?Если это так, то есть ли какой-либо смысл, кроме проблем с хранением, в использовании varchars?
Решение
Ан nvarchar столбец может хранить любые данные Unicode.А varchar Столбец ограничен 8-битной кодовой страницей.Некоторые люди думают, что varchar следует использовать, поскольку он занимает меньше места.Я считаю, что это не правильный ответ.Несовместимость кодовых страниц — это боль, а Unicode — лекарство от проблем с кодовыми страницами.Сегодня, когда диски и память дешевы, больше нет причин тратить время на возню с кодовыми страницами.
Все современные операционные системы и платформы разработки внутренне используют Юникод.Используя nvarchar скорее, чем varchar, вы можете избежать выполнения преобразований кодировки каждый раз, когда вы читаете или записываете в базу данных.Преобразования требуют времени и подвержены ошибкам.А восстановление после ошибок конвертации — нетривиальная задача.
Если вы взаимодействуете с приложением, которое использует только ASCII, я бы все равно рекомендовал использовать Unicode в базе данных.Алгоритмы сортировки ОС и базы данных будут лучше работать с Unicode.Unicode позволяет избежать проблем с преобразованием при взаимодействии с другой системы.И вы будете готовиться к будущему.И вы всегда можете убедиться, что ваши данные ограничены 7-битным ASCII для любой устаревшей системы, которую вам приходится поддерживать, даже пользуясь некоторыми преимуществами полного хранилища Unicode.
Другие советы
варчар:Символьные данные переменной длины, не относящиеся к Юникоду.Параметры сортировки базы данных определяют, какую кодовую страницу используют данные.
нварчар:Символьные данные Юникода переменной длины.Зависит от параметров сортировки базы данных для сравнения.
Вооружившись этими знаниями, используйте тот, который соответствует вашим входным данным (ASCII v.Юникод).
Я всегда использую 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 хранит данные в формате Unicode, поэтому, если вы собираетесь хранить многоязычные данные (более одного языка) в столбце данных, вам нужен вариант N.
Мои два цента
Индексы могут выйти из строя, если не используются правильные типы данных:
В SQL-сервере:Если у вас есть индекс по столбцу VARCHAR и вы представляете ему строку в Юникоде, SQL Server не использует этот индекс.То же самое происходит, когда вы представляете BigInt индексированному столбцу, содержащему SmallInt.Даже если BigInt достаточно мал, чтобы быть SmallInt, SQL Server не сможет использовать этот индекс.Наоборот, у вас не возникнет этой проблемы (при предоставлении SmallInt или Ansi-Code для индексированного столбца BigInt или NVARCHAR).Типы данных могут различаться в разных СУБД (система управления базами данных):
Помните, что каждая база данных имеет немного разные типы данных, и VARCHAR не везде означает одно и то же.В то время как SQL Server имеет VARCHAR и NVARCHAR, база данных Apache/Derby имеет только VARCHAR, а VARCHAR находится в Юникоде.
В основном нварчар хранит символы Юникода и варчар хранит символы, отличные от Unicode.
«Юникод» означает 16-битную схему кодировки символов, позволяющую кодировать символы из многих других языков, таких как арабский, иврит, китайский, японский, в одном наборе символов.
Это означает, что юникоды используют для хранения 2 байта на символ, а неюникоды используют для хранения только один байт на символ.Это означает, что для хранения юникодов требуется удвоенная емкость по сравнению с не-юникодами.
Ты прав. nvarchar хранит данные Unicode, пока varchar хранит однобайтовые символьные данные.Кроме различий в хранении (nvarchar требует в два раза больше места для хранения, чем varchar), о чем вы уже упомянули, основная причина предпочтения nvarchar над varchar будет интернационализация (т.е.хранение строк на других языках).
Я бы сказал, это зависит.
Если вы разрабатываете настольное приложение, операционная система которого работает в Unicode (как и все современные системы Windows), а язык изначально поддерживает Unicode (строки по умолчанию — Unicode, как в Java или C#), тогда используйте nvarchar.
Если вы разрабатываете веб-приложение, в котором строки вводятся в формате UTF-8, а язык — PHP, который по-прежнему не поддерживает Юникод изначально (в версиях 5.x), то varchar, вероятно, будет лучшим выбором.
nVarchar поможет вам хранить символы Юникода.Это лучший вариант, если вы хотите хранить локализованные данные.
Если для хранения символа используется один байт, существует 256 возможных комбинаций, и тем самым можно сохранить 256 различных символов.Параметры сортировки — это шаблон, определяющий символы и правила их сравнения и сортировки.
1252, то есть Latin1 (ANSI), является наиболее распространенным.Однобайтовые наборы символов также недостаточны для хранения всех символов, используемых во многих языках.Например, в некоторых азиатских языках тысячи символов, поэтому на каждый символ приходится использовать два байта.
Стандарт Юникод
Когда в сети используются системы, использующие несколько кодовых страниц, становится сложно управлять связью.Чтобы стандартизировать вещи, консорциум ISO и Unicode представил Юникод.Юникод использует два байта для хранения каждого символа.То есть можно определить 65 536 различных символов, поэтому почти все символы могут быть охвачены Unicode.Если два компьютера используют Юникод, каждый символ будет представлен одинаково, и преобразование не потребуется — в этом заключается идея Юникод.
SQL Server имеет две категории символьных типов данных:
- не-Юникод (char, varchar и текст)
- Юникод (nchar, nvarchar и ntext)
Если нам нужно сохранить данные символов из нескольких стран, всегда используйте Unicode.
Хотя NVARCHAR хранит Unicode, вы должны учитывать, что с помощью сортировки вы также можете использовать VARCHAR и сохраните данные о ваших местных языках.
Представьте себе следующий сценарий.
Параметры сортировки вашей БД — персидские, и вы сохраняете значение типа «علی» (персидское написание имени Али) в VARCHAR(10) тип данных.Проблем нет, и СУБД использует для его хранения всего три байта.
Однако, если вы хотите перенести свои данные в другую базу данных и увидеть правильный результат, ваша целевая база данных должна иметь те же параметры сортировки, что и целевая база данных, которая в этом примере является персидской.
Если ваши целевые параметры сортировки отличаются, в целевой базе данных вы увидите несколько вопросительных знаков (?).
Наконец, помните, что если вы используете огромную базу данных, предназначенную для использования вашего местного языка, я бы рекомендовал использовать местоположение вместо слишком большого количества пробелов.
Я считаю, что дизайн может быть разным.Это зависит от среды, в которой вы работаете.
Я должен сказать здесь (понимаю, что, вероятно, собираюсь открыться шиферу!), но, конечно, единственный раз, когда NVARCHAR на самом деле более полезно (обратите внимание на более там!), чем VARCHAR это когда все параметры сортировки во всех зависимых системах и в самой базе данных одинаковы...?Если нет, то преобразование сортировки все равно должно произойти, и поэтому VARCHAR так же жизнеспособно, как NVARCHAR.
Вдобавок к этому некоторые системы баз данных, такие как SQL-сервер (до 2012 г.) иметь размер страницы ок.8К.Итак, если вы хотите хранить данные, доступные для поиска, а не хранить их в чем-то вроде TEXT или NTEXT поле тогда VARCHAR обеспечивает полное пространство 8 КБ, тогда как NVARCHAR обеспечивает только 4 КБ (удвоение байтов, удвоение пространства).
Подводя итог, я полагаю, что использование любого из них зависит от:
- Проект или контекст
- Инфраструктура
- Система баз данных
Следовать Разница между типом данных Sql Server VARCHAR и NVARCHAR.Здесь вы можете увидеть это очень наглядно.
В целом nvarchar хранит данные в формате Unicode, поэтому, если вы собираетесь хранить многоязычные данные (более одного языка) в столбце данных, вам нужен вариант N.
Я просмотрел ответы, и многие, кажется, рекомендуют использовать 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(символьные данные переменной длины, не входящие в Юникод) размером до 8000.1. Это тип данных переменной длины.
Используется для хранения символов, отличных от Unicode.
Занимает 1 байт пространства для каждого символа
Nvarchar: Символьные данные Юникода переменной длины.
1. Это тип данных переменной длины.
2. Используется для хранения символов Юникода.
- Данные хранятся в кодировке Unicode.Каждый язык поддерживается.(например, языки арабский, немецкий, хинди и т. д.)
Джеффри Л. Уитледж с рейтингом репутации ~ 47000 рекомендует использовать nvarchar.
Соломон Руцки с рейтингом репутации ~33200 рекомендует:НЕ всегда используйте NVARCHAR.Это очень опасная и часто дорогостоящая позиция/подход.
Каковы основные различия в производительности между типами данных SQL Server varchar и nvarchar?
https://www.sqlservercentral.com/articles/disk-is-cheap-orly-4
Оба человека с такой высокой репутацией, что выбирает обучающийся разработчик баз данных sql-сервера?
В ответах и комментариях содержится множество предупреждений о проблемах с производительностью, если вы непоследовательны в выборе.
Есть комментарии за/против nvarchar по производительности.
Есть комментарии за/против varchar для производительности.
У меня есть особое требование к таблице со многими сотнями столбцов, что само по себе, вероятно, необычно?
Я выбираю varchar, чтобы не приближаться к предельному размеру записи таблицы в 8060 байт, установленному в SQL*server 2012.
Для меня использование nvarchar превышает лимит в 8060 байт.
Я также думаю, что мне следует сопоставить типы данных связанных кодовых таблиц с типами данных основной центральной таблицы.
Я видел использование столбца varchar на этом месте работы, в правительстве Южной Австралии, предыдущими опытными разработчиками баз данных, где количество строк таблицы будет составлять несколько миллионов или более (и очень мало столбцов nvarchar, если таковые имеются, в этих очень больших таблицы), поэтому, возможно, ожидаемые объемы строк данных станут частью этого решения.
nvarchar безопасен в использовании по сравнению с varchar чтобы сделать наш код свободным от ошибок (несоответствие типов), потому что nvarchar также позволяет использовать символы Юникода.Когда мы используем where условие в запросе SQL Server, и если мы используем = оператор, он несколько раз выдаст ошибку.Вероятная причина этого в том, что наш столбец сопоставления будет определен в varchar.Если бы мы определили это в nvarchar этой проблемы не было.Тем не менее мы придерживаемся varchar и избегайте этой проблемы, нам лучше использовать LIKE ключевое слово, а не =.
