Oracle Text не будет работать с NVARCHAR2. Что еще может быть недоступно?

Если у вас есть что-то близкое к выбору, используйте набор символов Unicode для всей базы данных. Жизнь в целом становится просто ослепительно легче.

• Существует множество сторонних утилит и библиотек, которые просто не поддерживают столбцы 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 в C++, на самом деле не означает, что вам не нужно будет вносить (потенциально значительные) изменения для поддержки столбцов NCHAR/NVARCHAR2.

Мы также используем SQL*Loader и SQL*Plus для связи с базой данных для базовых операторов или для обновления между версиями продукта. Мы не слышали о какой-либо конкретной проблеме со всем этим программным обеспечением, касающимся NVARCHAR2.

Все эти приложения работают с NCHAR/NVARCHAR2. NCHAR/NVARCHAR2 вносит некоторые дополнительные сложности в сценарии, особенно если вы пытаетесь закодировать строковые константы, которые не могут быть представлены в наборе символов базы данных. Однако вы, безусловно, можете обойти проблемы.

Мы также не знаем, что администраторы баз данных среди наших клиентов хотели бы использовать другие инструменты в базе данных, которые не могут поддерживать данные в NVARCHAR2, и мы не очень обеспокоены тем, что их инструменты могут нарушить работу, в конце концов, они опытны в своей работе и могут найти другие инструменты при необходимости.

Хотя я уверен, что ваши клиенты могут найти альтернативные способы работы с вашими данными, если ваше приложение не очень хорошо работает с их корпоративным инструментом отчетности или их корпоративным инструментом ETL или любыми другими настольными инструментами, с которыми они столкнулись, это очень вероятно. что клиент будет винить ваше приложение, а не свои инструменты. Это, вероятно, не будет препятствием для шоу, но также нет никакой пользы в том, чтобы причинять клиентам горе без необходимости. Возможно, это не побудит их использовать продукт конкурента, но и не заставит их хотеть использовать ваш продукт.

Можем ли мы также ожидать падения производительности, если наше приложение (скомпилированное под Visual C++), которое использует wchar_t для хранения UTF-16, должно выполнять преобразования кодирования для всех обрабатываемых данных?

Я не уверен, о каких «конверсиях» вы говорите. Это может вернуться к моему первоначальному вопросу о том, заявляете ли вы, что вы обходите уровень Oracle NLS, чтобы выполнить преобразование набора символов самостоятельно.

Суть в том, что я не вижу никаких преимуществ в использовании NCHAR/NVARCHAR2, учитывая то, что вы описываете. Есть много потенциальных недостатков их использования. Однако, даже если вы можете устранить 99% недостатков как не имеющих отношения к вашим конкретным потребностям, вы все равно столкнетесь с ситуацией, когда в лучшем случае это будет размывание между двумя подходами. Учитывая это, я бы предпочел использовать подход, который максимизирует гибкость в будущем, и это преобразование всей базы данных в Unicode (предположительно AL32UTF8) и просто использование этого.