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

Мы собираемся перенести приложение, чтобы он поддерживал Unicode и должен был выбирать между набором символов Unicode для всей базы данных или столбцами Unicode, хранящимися в N [VAR] CHAR2.

Мы знаем, что у нас больше не будет возможности индексировать содержимое столбца с помощью Oracle Text, если мы выберем NVARCHAR2, потому что Oracle Text может индексировать столбцы только по типу CHAR.

Кроме того, возможно ли, что другие основные различия возникают при сборе урожая из возможностей Oracle?

Кроме того, возможно ли, что некоторые новые функции добавлены в более новые версии Oracle, но поддерживаются только столбцы CHAR или столбцы NCHAR, но не оба?

Спасибо за ваши ответы.

Примечание после ответа Джастина:

Спасибо за ваш ответ. Я обсужу ваши вопросы, применимые к нашему делу:

Наше приложение, как правило, является единственным в базе данных Oracle и заботится о сами данные. Другое программное обеспечение, которое подключается к базе данных, ограничено Toad, Tora или SQL.

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

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

Ваши последние два момента более проницательны для нашего случая. Мы не используем многие встроенные пакеты от Oracle, но это все еще происходит. Мы рассмотрим это проблема.

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

Ответ 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) и просто использует это.