Этот ответ содержит некоторые соображения о преимуществах и недостатках упаковки ваших таблиц в PL/SQL-таблицах (API таблицы) для операций CRUD.
Understanding the differences between Table and Transaction API's
Там была также хорошая дискуссия по этому вопросу в последние годы в Великобритании Oracle User Group - общий вывод был против использования таблиц API-интерфейсов и интерфейсов API транзакций, по той же причине - сила пл/sql - это процедурный контроль над операторами SQL, в то время как TAPI отталкивают вас от написания SQL-операций на основе набора и обработки строк за строкой.
Аргумент для TAPI - это то, где вы можете использовать какую-либо политику доступа, но Oracle предлагает множество других способов сделать это (мелкозернистый контроль доступа, ограничения, триггеры для вставки/обновления/etc могут быть используется для заполнения значений по умолчанию и обеспечения того, чтобы вызывающий код передавал действительный запрос).
Я бы определенно посоветовал не переносить таблицы в типы объектов PL/SQL.
Большая часть производительности с использованием pl/sql связана с тем, что вы можете легко определить вещи с точки зрения базовой структуры базы данных - тип записи строки может быть просто определен как% ROWTYPE и будет автоматически влиять, когда изменения структуры таблицы.
myRec myTable%ROWTYPE
INSERT INTO table VALUES myRec;
Это также относится к коллекции, основанной над этими типами, и есть мощные массовые операции, которые могут быть использованы для извлечения & вставки целых коллекций.
С другой стороны, для каждого типа объектов должны быть явно затронуты типы объектов, каждый раз, когда вы хотите их изменить, для каждого изменения таблицы требуется, чтобы тип объекта был затронут и выпущен, удвоив вашу работу.
Также может быть сложно освободить изменения, если вы используете наследование и коллекции типов (вы можете «заменить» пакет, но не можете заменить тип, если он используется другим типом).
Это не помещает OO PL/SQL вниз - есть места, где он определенно упрощает код (т. Е. Избегает дублирования кода, в любом месте, где вы явно выиграете от полиморфизма), - но лучше всего понимать и играть в сильные стороны язык и основная сила в том, что язык тесно связан с базовой БД.
Это говорит о том, что я часто создаю процедуры для построения записи по умолчанию, вставляю запись и т. Д. - достаточно часто, чтобы иметь макросы редактора для нее, - но я никогда не нашел хороший аргумент для автоматического создания этого кода для все таблицы (хороший способ создать много неиспользуемого кода?)
Что я имею в виду, так это то, что я могу создать набор объектов Oracle (используя «создавать или заменять типы FOO как объекты ..», созданные с помощью скрипта) , что облегчит дальнейшее развитие программного обеспечения pl/sql (в основном это будет содержать операции CRUD). Как вы думаете, будут ли эти объекты эффективными? – Arino