Недостатки установки всей кодировки БД в Unicode против некоторых NVARCHAR2 в Oracle DB?

я бы сильно склонялся к изменению набора символов базы данных.

есть потенциальные недостатки этого

• если вы храните данные, которые не находятся в 7-битном наборе символов ASCII в других столбцах, вы увеличите объем пространства, необходимого для хранения данных. Предполагая, что ваш существующий набор символов является одним из 8-битных наборов символов, которые позволяют хранить английский язык плюс несколько других языков, любой неанглийский символы в данных, как правило, требуют 2 или более байт на символ. Например, если вы храните символ "h", это английский символ, который является частью 7-битного набора символов ASCII, поэтому для него потребуется 1 байт либо в вашем однобайтовом наборе символов, либо в вашем наборе символов Юникода. Если вы храните символ "À", с другой стороны, это не английский и не Часть 7-битного набора символов ASCII, поэтому для него потребуется 2 байта хранения в символе Юникода установите против 1 байта в существующем однобайтовом наборе символов. Для других символов потребуется 3 байта памяти.
• вам придется заботиться о семантике символов и байтов, когда вы объявите VARCHAR2. По умолчанию VARCHAR2(50) выделяет 50 байтов памяти, что позволит вам хранить от 16 до 50 символов, если вы используете набор символов AL32UTF8, а не простое сопоставление 1:1, как это происходит, если вы используете однобайтовый набор символов. Это потребует либо того, что вы увеличьте размер столбцов (т. е. утроьте их), чтобы гарантировать, что они хранят соответствующее количество символов или что вы указываете семантику длины символа при объявлении столбца (т. е. VARCHAR2(50 CHAR)) или что вы установили свой NLS_LENGTH_SEMANTICS to CHAR перед созданием объектов, чтобы изменить значение по умолчанию на семантику длины символа. На форуме глобализации Oracle идет дискуссия о том, уместно ли измените NLS_LENGTH_SEMANTICS в экземпляре уровеньNLS_LENGTH_SEMANTICS на уровне сеанса, который Sergiusz не возражает, но требует, чтобы вы делали это каждый раз, когда вы запускаете сценарий, который может быть проблемой.
• большинство инструментов не особенно хорошо справляются с запросами к словарю данных, где семантика символов были использованы для создания столбца. Они неправильно используют CHAR_LENGTH и DATA_LENGTH столбцы, где они хотят длину в символах против длины в байтах. Это может быть незначительная проблема для вас или серьезная боль, если у вас есть существующие инструменты/ скрипты/ и т. д. это запускает запросы к словарю данных для создания DDL или определения того, сколько памяти необходимо выделить или в какой-либо другой ситуации, когда вы в конечном итоге получаете фанки результаты.

• обращение NVARCHAR2 столбцы обычно требуют изменения кода приложения. Поскольку у тебя будет и то, и другое!--0--> и NVARCHAR2 столбцы, эти изменения кода и настройки конфигурации могут быть нетривиальными и часто являются серьезным раздражением. Неизбежно вы обнаружите, что вы неправильно сопоставили определенный столбец в каком-либо приложении, и вы столкнетесь с ошибками повреждения данных, которые являются болью для выследить. Это тем более верно, чем больше уровней абстракции у вас есть между вашей базой данных и вашим приложением.
• если 1% столбцов должны поддерживать Unicode сегодня, это неизбежно, что больше столбцов должны будут поддерживать Unicode завтра. По мере добавления дополнительных требований измените тип данных столбца с VARCHAR2 до NVARCHAR2 это боль - вам нужно добавить новый столбец, скопировать данные и удалить старый столбец, переименовать новый столбец и разобраться с результирующая миграция строк. Затем вам придется внести изменения во все существующие приложения, чтобы они правильно отображали столбец. Когда бизнес решает, что еще один столбец должен поддерживать дополнительные языки, а ваша база данных и приложения уже поддерживают Unicode, этот уровень усилий и тестирования будет казаться чрезмерным.
• операторы SQL должны быть закодированы в наборе символов базы данных. Это создает проблемы, если вы хотите использовать данные из NVARCHAR2 столбец как литерал в инструкции SQL либо в приложении (скажем, чтобы избежать подглядывания переменной привязки или лучше использовать гистограмму), либо как часть производственной поддержки, когда вы хотите отслеживать проблемы в данных.
• наборы символов Юникода-это направление, которое Oracle настоятельно рекомендует и использование NVARCHAR2 столбцы сильно обескуражены. Это, вероятно, не имеют непосредственных практических последствий, но если ваша система должна быть вокруг количество лет, вполне вероятно, что будут последствия в будущем.

Сергиуш очень хорошо резюмирует совет Oracle в этой теме

Совет Oracle:

• для любой новой базы данных создайте ее с набором символов AL32UTF8 и забудьте о типах данных NCHAR.
• для любого существующего приложения, которое будет сделано многоязычным, перенесите базу данных бэкэнда в AL32UTF8 и забудьте о NCHAR тип данных.
• для любой существующей базы данных не Unicode, обслуживающей большую устаревшую прикладную систему, слишком дорогостоящую или невозможную для миграции Unicode, к которому вас попросят добавить дополнительный модуль, который должен поддержка многоязычных данных и отдельных баз данных мало смысла, вы можете рассмотреть столбцы NVARCHAR2 для этого многоязычного данные.