Каков тип данных на национальном языке SQL (NCHAR)?

Как и 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'' литералы)?

ОТВЕТЫ

Ответ 1

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

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

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

Ответ 2

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

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

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

Ответ 3

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

Кстати, это то же самое "различие", которое имеет стандарт С++ между char и wchar_t. Реликвия Темных Возрастов Кодировки символов, когда каждая комбинация языка/ОС имеет свой собственный набор символов.

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

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

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

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