Какой самый лучший (самый быстрый, самый простой, самый эффективный) способ передачи структурированных данных в и из Oracle

Question

Я хочу абстрагировать большое хранилище базы данных (реляционное, OLTP) от прикладного уровня, чтобы приложение рассматривало базу данных как службу. Естественный способ сделать это - вызвать sprocs, но традиционно они следуют парадигмам CRUD, и в соответствии с моей абстракцией, я хочу абстрагировать все знания о структурах данных в базе данных и сосредоточиться на бизнес-процессах.

Так что вместо бизнес-процесса «Сохранить счет» это будет ...

1. Старт транзакции
2. Создать заголовок счета
3. Для позиций счетов-фактур
   1. Создание позиций счетов-фактур
4. Подтвердить транзакцию

... вместо этого я хочу передать в базу данных структурированные данные, представляющие счет-фактуру.

Я могу передать XML-документ, содержащий счет, но это то, чего я хочу избежать на стороне базы данных:

1. Синтаксический анализ XML
2. Проверка XML
3. Извлечение параметров и привязка к объектам Oracle PL / SQL

Конечно, во всех случаях, независимо от решения, это должно быть сделано. Однако я не хочу платить штраф за документ XML (налог на угловую скобку).

Отсюда возникает вопрос - каков наиболее эффективный способ отправки и получения и структурирования данных в хранимых процедурах Oracle?

Я хотел бы услышать от тех, кто хочет отстаивать JSON, ATOM или другие форматы.

Также рассмотрите нативный или двоичный механизмы для достижения этой цели. А как насчет создания и отправки в таблицах Oracle (наборы данных памяти)? Кто-нибудь делал это раньше? Что, где ваш опыт?

Answer 1

Поскольку вы используете Oracle, синтаксический анализ XML в хранимой процедуре не имеет большого значения. ИМО есть только три разумных пути:

• Использование DAO на клиентах, которые знают структуру базы данных
• Используйте хранимую процедуру, чтобы иметь немного абстракции
• Использовать XML

Любой другой формат структурированного текста (JSON и т. Д.) Уступает, поскольку XML - это формат , для которого у вас уже есть синтаксический анализатор в Oracle.

Answer 2

Может быть, исследовать объектно-реляционные представления.

Смотрите эти ссылки для начальных точек ...

Документы Oracle 9i - «Применение объектной модели к реляционным данным»

Спросите Тома - «Проектирование реляционных VS объектно-ориентированных баз данных»

Answer 3

Я не понимаю, почему кто-то хотел бы сделать что-то вроде «разбора» и «проверки» в базе данных.

Может случиться так, что мы используем очень сильно загруженные базы данных в моей работе, поэтому моя точка зрения довольно субъективна, но в основном все, что можно сделать вне базы данных, делается снаружи, поскольку база данных является узким местом для большинства приложений (и «снаружи» можно легко распараллелить).

Вот что мы используем на работе:

| ID | Индекс 1 | Индекс 2 | Индекс 3 | ... | Большой блок данных |

По сути, индексы обеспечивают возможность поиска, а «Большой блок данных» находится под контролем приложений. Обычно это сжатые сериализованные (версионные) данные (некоторые команды хранят около 300 КБ в этом двоичном объекте;)).

Конечно, для этого требуется, чтобы интерфейс (или библиотека) фактически выполнял сериализацию + сжатие или декомпрессию + десериализацию единообразным образом.

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

Answer 4

Я хочу абстрагировать большое хранилище базы данных (реляционное, OLTP) от уровня приложения, чтобы приложение рассматривало базу данных как службу.

Для этого и нужен слой DAO. Для кода приложения DAO - это постоянный уровень (сервис в ваших терминах). DAO знает, как хранить структурированный документ.

Полагаю, вам нужно выполнить SQL-запросы к сохраненным документам.

Хотя существует специфичный для Oracle формат XML, я бы воздержался от его использования, поскольку он связывает ваш код с Oracle. Пока работает стандартный SQL, используйте это.

Answer 5

Это зависит. Вы можете хранить данные в любой форме в виде большого объекта. Основная причина, по которой никто этого не делает, заключается в том, что вы храните данные в базе данных, чтобы вы могли искать через нее. Интернет был хорошей идеей, пока Google не пришел и не позволил найти вещей.

Так что вы должны каким-то образом анализировать данные. Вы можете разобрать его на клиенте и отправить SQL вставки / обновления. Если вы сделаете это с вашим любимым языком OO, у вас будет OR OR (который может загружать и сохранять «объекты» в простых таблицах SQL). Таким образом, тяжелая работа (анализ) выполняется на многих клиентах, в то время как база данных просто хранит и ищет данные.

Answer 6

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

INSERT
INTO    dest_table
SELECT  *
FROM    TABLE(:mycollection)