2009-08-13 5 views
11

Я сохраняю имя и фамилию по 30 символов каждый. Что лучше varchar или nvarchar.varchar или nvarchar

Я читал, что nvarchar занимает в два раза больше места по сравнению с varchar и что nvarchar используется для интернационализации.

Так что вы предлагаете использовать: nvarchar или varchar?

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

+1

http://stackoverflow.com/questions/35366/varchar-vs-nvarchar-performance –

ответ

17

В принципе, nvarchar означает, что вы можете обрабатывать множество алфавитов, а не только обычный английский. Технически это означает поддержку Unicode, а не только ANSI. Это означает знаки двойной ширины или примерно в два раза больше места. В эти дни дисковое пространство настолько дешево, что вы могли бы использовать nvarchar с самого начала, а не испытывать боль от необходимости менять в течение жизни продукта.

Если вы уверены, что вам понадобится только один язык, который вы можете использовать с varchar, в противном случае я бы пошел с nvarchar.

Это обсуждалось на SO до here.

EDITED: изменено ascii на ANSI, как указано в комментарии.

+3

является nitpicky: на самом деле VARCHAR хранит данные ANSI - 8-бит, как правило, на основе кодовой страницы, такой как западноевропейская или исландская, или что вам нужно :-) Это ANSI-8-бит - не ASCII (= 7-бит) –

6

Прежде всего, чтобы уточнить, nvarchar хранит данные Unicode, а varchar хранит данные ANSI (8 бит). Они функционируют одинаково, но nvarchar занимает в два раза больше места.

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

Это также зависит от сортировки базы данных. Напр. вы не сможете хранить русские символы в поле varchar, если сортировка базы данных LATIN_CS_AS. Но если вы работаете над локальным приложением, которое будет использоваться только в России, вы настроили сопоставление базы данных на русский язык. Что это будет сделано, так это то, что он позволит вам вводить русские символы в поле varchar, сохраняя некоторое пространство.

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

2

У меня есть красный, который nvarchar принимает дважды как varchar.

Да.

nvarchar используется для интернационализации.

Да.

что вы предлагаете мне использовать nvarchar или varchar?

Это зависит от приложения.

+1

Неправильно. Для nvarchar требуется в два раза больше места, чем varchar. Вы можете легко проверить это, используя функцию DATALENGTH. – Guffa

+0

Спасибо Киртан. Приносим извинения за причиненные неудобства. – adatapost

1

По умолчанию перейдите к nvarchar. В наши дни очень мало оснований идти с варчаром, и все причины идти с nvarchar (допускает международные символы, как обсуждалось).

1

varchar - 1 байт на символ, nvarchar - 2 байта на символ.

Вы будете использовать больше пространства с nvarchar, но есть еще много допустимых символов. Дополнительное пространство ничтожно, но вы можете пропустить эти дополнительные персонажи в будущем. Даже если вы не ожидаете необходимости интернационализации, люди часто будут иметь неанглийские символы (например, é, ñ или ö) в своих именах.

Я предлагаю вам использовать nvarchar.

0

Тип nvarchar - Unicode, поэтому он может обрабатывать практически любой символ, который существует на каждом языке на планете. Символы хранятся как UTF-16 или UCS-2 (не уверены, какие и различия тонкие), поэтому каждый символ использует два байта.

Тип varchar использует 8-битный набор символов, поэтому он ограничен 255 символами набора символов, который вы выбираете для этого поля. Существуют разные символы, которые обрабатывают разные группы символов, поэтому обычно это достаточно, чтобы текст был локальным для страны или региона.

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

1

У меня есть красный, что NVARCHAR занимает в два раза VARCHAR

Да. Согласно Microsoft: «Размер памяти, в байтах, в два раза превышает количество введенных символов + 2 байта» (http://msdn.microsoft.com/en-us/library/ms186939(SQL.90).aspx).

Но хранение дешево; Я никогда не беспокоюсь о нескольких дополнительных байтах.

Кроме того, сохраните себе проблемы в будущем и установите максимальную ширину на более щедрую, например, на 100 символов. Для этого нет никаких накладных расходов на хранение, когда вы используете varchar или nvarchar (в отличие от char/nchar). Вы никогда не знаете, когда вы столкнетесь с тройной фамилией или длинным иностранным именем, которое превышает 30 символов.

nvarchar используется для интернационализации.

nvarchar может хранить любой символ юникода, например символы из нелатинских скриптов (арабский, китайский и т. Д.). Я не уверен, как ваше приложение будет принимать данные (через Интернет, с помощью инструментария GUI и т. Д.), Но вполне вероятно, что всякая технология, которую вы используете, поддерживает unicode из коробки. Это означает, что для любых введенных пользователем данных (таких как имя) есть всегда возможность получения нелатинских символов, если не сейчас, то в будущем.

Если бы я строил новое приложение, я использовал бы nvarchar. Назовите это «будущим», если хотите.

0

на производительность:
причина использовать VARCHAR над NVARCHAR является то, что вы можете иметь в два раза больше символов в индексах! ключи индекса ограничены 900 байт
на удобстве использования:
если приложение только когда-либо предназначено для английской аудитории & содержат английские названия, использование VARCHAR

+0

Никогда столкнулся с длиной более 450 символов. – zszep

0

данных для хранения: «Сунил»

VARCHAR (5) принимает 7B nvarchar (5) принимает 12B