Разница между NVARCHAR в Oracle и SQL Server?

Мы переносим некоторые данные с сервера sql на oracle. Для столбцов, определенных как NVARCHAR в SQL-сервере, мы начали создавать столбцы NVARCHAR в Oracle, думая, что они похожи. Но похоже, что это не так.

Я прочитал пару сообщений о stackoverflow и хочу подтвердить мои выводы.

Oracle VARCHAR2 уже поддерживает unicode, если набор символов базы данных - это AL32UTF8 (что верно для нашего случая).

SQLServer VARCHAR не поддерживает юникод. SQLServer явно требует наличия столбцов в типе NCHAR/NVARCHAR для хранения данных в Юникоде (в частности, в формате 2-байтового формата UCS-2).

Следовательно, было бы правильно сказать, что столбцы SQL Server NVARCHAR можно/нужно перенести в качестве столбцов Oracle VARCHAR2?

Ответ 1

Да, если ваша база данных Oracle создана с использованием набора символов Unicode, NVARCHAR в SQL Server должен быть перенесен в VARCHAR2 в Oracle. В Oracle существует тип данных NVARCHAR, позволяющий приложениям хранить данные с помощью набора символов Unicode, когда набор символов базы данных не поддерживает Unicode.

Одна вещь, о которой нужно помнить при миграции, - это семантика длины символов. В SQL Server a NVARCHAR(20) выделяет пространство для 20 символов, для которого в UCS-2 требуется до 40 байтов. В Oracle по умолчанию a VARCHAR2(20) выделяет 20 байтов памяти. В наборе символов AL32UTF8 это потенциально достаточно места для 6 символов, хотя, скорее всего, он будет обрабатывать гораздо больше (для одного символа в AL32UTF8 требуется от 1 до 3 байтов. Вероятно, вы хотите объявить свои типы Oracle как VARCHAR2(20 CHAR), который указывает, что вы хотите выделить место для 20 символов, независимо от того, сколько байтов требуется. Это, как правило, намного проще в общении, чем попытка объяснить, почему допустимы некоторые 20 символьных строк, в то время как другие 10 символьных строк отклоняются.

Вы можете изменить семантику длины по умолчанию на уровне сеанса, чтобы любые созданные вами таблицы без указания семантики длины использовали семантику символов, а не байтов

ALTER SESSION SET nls_length_semantics=CHAR;

Это позволяет избежать ввода CHAR каждый раз, когда вы определяете новый столбец. Также возможно установить это на системном уровне, но это не поощряет команда NLS. По-видимому, не все сценарии, которые предоставляет Oracle, были тщательно протестированы в отношении баз данных, где был изменен NLS_LENGTH_SEMANTICS. И, вероятно, очень мало сторонних скриптов.