Ответ 1
Если у вас есть что-то близкое к выбору, используйте набор символов Юникода для всей базы данных. Жизнь в целом просто ослепительно проще.
- Существует множество сторонних утилит и библиотек, которые просто не поддерживают столбцы NCHAR/NVARCHAR2 или не делают работу с столбцами NCHAR/NVARCHAR2 приятными. Это очень раздражает, например, когда ваш блестящий новый инструмент отчетности не может сообщать о ваших данных NVARCHAR2.
- Для настраиваемых приложений работа с столбцами NCHAR/NVARCHAR2 требует перехода через некоторые обручи, которые работают с кодированными столбцами CHAR/VARCHAR2 Unicode. Например, в коде JDBC вы постоянно вызываете метод Statement.setFormOfUse. Другие языки и рамки будут иметь другие ошибки; некоторые из них будут относительно хорошо документированы, а незначительные другие будут относительно неясными.
- Многие встроенные пакеты будут принимать (или возвращать) VARCHAR2, а не NVARCHAR2. Вы все равно сможете называть их из-за неявного преобразования, но вы можете столкнуться с проблемами преобразования набора символов.
- В общем, возможность избежать проблем с преобразованием набора символов в базе данных и отбросить эти проблемы до края, где база данных фактически отправляет или получает данные от клиента, облегчает работу по разработке приложения. Это достаточно, чтобы отлаживать проблемы преобразования набора символов, возникающие в результате сетевой передачи, - выяснение того, что некоторые данные были повреждены, когда хранимая процедура объединила данные из VARCHAR2 и NVARCHAR2 и сохранила результат в VARCHAR2 до того, как она была отправлена по сети, быть мучительным.
Oracle разработал типы данных NCHAR/NVARCHAR2 для случаев, когда вы пытаетесь поддерживать устаревшие приложения, которые не поддерживают Unicode в той же базе данных, что и новые приложения, использующие Unicode, и для случаев, когда полезно хранить некоторые данные Unicode с другим кодированием (т.е. у вас есть большое количество японских данных, которые вы предпочитаете хранить с использованием кодировки UTF-16 в NVARCHAR2, а не в кодировке UTF-8). Если вы не находитесь в одной из этих двух ситуаций, и это не похоже на вас, я бы избегал NCHAR/NVARCHAR2 любой ценой.
Отвечая на ваши последующие действия
Наше приложение, как правило, базы данных Oracle и сами данные. Другое программное обеспечение, которое подключение к базе данных ограничено Разработчик Toad, Tora или SQL.
Что значит "заботится о самих данных"? Я надеюсь, вы не говорите, что вы настроили приложение для обхода программ преобразования символьных наборов Oracle и что вы делаете все преобразования набора символов самостоятельно.
Я также предполагаю, что вы используете какой-то API/библиотеку для доступа к базе данных, даже если это OCI. Вы изучили, какие изменения необходимо внести в приложение для поддержки NCHAR/NVARCHAR2 и поддерживает ли API, который вы используете, NCHAR/NVARCHAR2? Тот факт, что вы получаете данные Unicode на С++, на самом деле не указывает на то, что вам не нужно будет делать (потенциально значительные) изменения для поддержки столбцов NCHAR/NVARCHAR2.
Мы также используем SQL * Loader и SQL * Plus для общаться с базой данных для базовые заявления или обновить версии продукта. Мы не слышал о какой-либо конкретной проблеме со всеми это программное обеспечение в отношении NVARCHAR2.
Все эти приложения работают с NCHAR/NVARCHAR2. NCHAR/NVARCHAR2 вносит некоторые дополнительные сложности в скрипты, особенно если вы пытаетесь кодировать строковые константы, которые не могут быть представлены в наборе символов базы данных. Тем не менее, вы можете решить проблемы.
Мы также не знаем, что база данных администраторы среди наших клиентов хотели бы использовать другие инструменты на база данных, которая не может поддерживать данные на NVARCHAR2, и мы на самом деле не обеспокоены ли их инструменты в конце концов, они квалифицированы в их работу и могут найти другие инструменты, если необходимо.
В то время как я уверен, что ваши клиенты могут найти альтернативные способы работы с вашими данными, если ваше приложение не играет хорошо с помощью своего инструмента корпоративного отчета или своего корпоративного инструмента ETL или каких бы то ни было настольных инструментов, с которыми они сталкиваются, очень вероятно, что клиент будет обвинять ваше приложение, а не их инструменты. Вероятно, это не будет пробной пробкой, но также нет никакой пользы, чтобы причинить клиентам печаль излишне. Это может не заставить их использовать продукт конкурента, но он не заставит их стремиться охватить ваш продукт.
Можно ли ожидать, что производительность поломка, если наше приложение (то есть скомпилированный под Visual С++), который использует wchar_t для хранения UTF-16, должен выполнять преобразования кодировки на всех обработанных данных?
Я не уверен, о каких "конверсиях" вы говорите. Это может вернуться к моему первоначальному вопросу о том, заявляете ли вы, что вы обходите слой Oracle NLS, чтобы преобразовать набор символов самостоятельно.
Моя нижняя строка, однако, заключается в том, что я не вижу никаких преимуществ при использовании NCHAR/NVARCHAR2, учитывая то, что вы описываете. Есть много потенциальных недостатков для их использования. Даже если вы можете устранить 99% недостатков как не относящихся к вашим конкретным потребностям, однако, вы по-прежнему сталкиваетесь с ситуацией, когда в лучшем случае это стирка между двумя подходами. Учитывая это, я бы скорее пошел с подходом, который максимизирует гибкость в будущем и конвертирует всю базу данных в Unicode (предположительно AL32UTF8) и просто использует это.