Что такое тип данных национального характера SQL (NCHAR)?

Question

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

Answer 1

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

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

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

Answer 2

В Oracle набор символов базы данных может быть многобайтовым набором символов, поэтому вы можете хранить всевозможные символы там ... но вам нужно понять и определить длину столбцов соответствующим образом (либо в БАЙТЫ или ХАРАКТЕРЫ).

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

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

Answer 3

Между тем стандартом SQL92 объясняет особенность еще менее услужливо, только о том, что национальный характер хранится в наборе символов реализации. В отличие от простого CHARACTER, который хранится в наборе символов, определяемом реализацией . Каким может быть и другой набор символов, установленный для реализации . Или нет.

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

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

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

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

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