Для чего действительно нужен тип данных национального символа (NCHAR) SQL? - PullRequest
Новая
       11

Для чего действительно нужен тип данных национального символа (NCHAR) SQL?

49 голосов
/ 09 октября 2010

Кроме CHAR (CHARACTER) и VARCHAR (CHARACTER VARYING), SQL предлагает типы NCHAR (NATIONAL CHARACTER) и NVARCHAR (NATIONAL CHARACTER VARYING). В некоторых базах данных этот тип данных лучше использовать для символьных (недвоичных) строк:

  • В SQL Server NCHAR хранится как UTF-16LE и является единственным способом надежного хранения не-ASCII-символов, CHAR является только однобайтовой кодовой страницей;

  • В Oracle NVARCHAR может храниться как UTF-16 или UTF-8, а не как однобайтовое сопоставление;

  • Но в MySQL NVARCHAR равен VARCHAR, так что это не имеет значения, любой тип может быть сохранен с UTF-8 или любым другим сопоставлением.

Итак, что на самом деле означает NATIONAL, если вообще что-нибудь? Документы производителей сообщают вам только о том, какие наборы символов используются их собственными СУБД, а не о фактическом обосновании. Между тем стандарт SQL92 объясняет эту функцию еще менее полезно, заявляя только, что NATIONAL CHARACTER хранится в наборе символов, определяемом реализацией. В отличие от простого CHARACTER, который хранится в наборе символов, определяемом реализацией. Это может быть другой набор символов, определенный реализацией. Или нет.

Спасибо, ANSI. Thansi.

Следует ли использовать NVARCHAR для всех символьных (недвоичных) целей хранения? Существуют ли в настоящее время популярные СУБД, в которых они будут делать что-то нежелательное, или которые просто не распознают ключевое слово (или N'' литералы)?

Ответы [ 3 ]

14 голосов
/ 09 октября 2010

«НАЦИОНАЛЬНЫЙ» в данном случае означает символы, характерные для разных национальностей.В дальневосточных языках особенно много символов, поэтому одного байта недостаточно, чтобы различить их все.Так что если у вас есть приложение на английском (ascii) или поле только на английском , вы можете использовать старые типы CHAR и VARCHAR, которые допускают использование только одного байта на символ.

Тем не менее, большую часть времени вы должны использовать NCHAR / NVARCHAR.Даже если вы не думаете, что вам нужно поддерживать (или потенциально поддерживать) несколько языков в ваших данных, даже приложения, предназначенные только для английского языка, должны быть способны разумно обрабатывать атаки безопасности с использованием символов иностранных языков.

По моему мнению, единственное место, где старые типы CHAR / VARCHAR по-прежнему предпочтительнее, - это часто используемые внутренние коды ascii и данные на платформах, таких как Sql Server, которые поддерживают различие, - данные, которые будутэквивалент enum на клиентском языке, таком как C ++ или C #.

4 голосов
/ 10 декабря 2010

Между тем стандарт SQL92 объясняет функция еще менее услужлива, указав только этот НАЦИОНАЛЬНЫЙ ХАРАКТЕР хранится в определенной реализацией набор символов. В отличие от простого ХАРАКТЕР, который хранится в определяемый реализацией набор символов. Который может быть другим определяемый реализацией набор символов. Или нет.

По совпадению, это то же самое "различие", которое стандарт C ++ проводит между char и wchar_t. Реликвия Dark Ages of Character Encoding, когда каждая комбинация языка / ОС имеет свой собственный набор символов.

Следует ли использовать NVARCHAR для всех символьное (недвоичное) хранилище цели?

Неважно, является ли объявленный тип вашего столбца VARCHAR или NVARCHAR. Но важно использовать Unicode (будь то UTF-8, UTF-16 или UTF-32) для всех целей хранения символов.

Существуют ли в настоящее время популярные СУБД в что он будет делать что-то нежелательное

Да: в MS SQL Server использование NCHAR делает ваши (английские) данные занимающими вдвое больше места. К сожалению, UTF-8 пока не поддерживается .

3 голосов
/ 10 октября 2010

В Oracle набор символов базы данных может быть многобайтовым набором символов, так что вы можете хранить в нем все типы символов .... но вам необходимо понимать и определять длину столбцов соответствующим образом (в любом из байтов или CHARACTERS).

NVARCHAR дает вам возможность иметь набор символов базы данных, который является однобайтовым (что уменьшает вероятность путаницы между столбцами размера BYTE или CHARACTER), и использовать NVARCHAR в качестве многобайтового. Смотрите здесь .

Поскольку я преимущественно работаю с английскими данными, я бы использовал многобайтовый набор символов (в основном UTF-8) в качестве набора символов базы данных и игнорировал NVARCHAR. Если я унаследовал старую базу данных, которая была в однобайтовом наборе символов и была слишком большой для преобразования, я могу использовать NVARCHAR. Но я бы предпочел не делать этого.

...