Реализация приложения на PL / SQL

Question

Мы разрабатываем веб-приложение, которое, согласно моей спецификации, должно иметь бэкэнд, полностью написанный на PL / SQL (хранимые процессы и т. Д.). Кто-нибудь есть какие-либо советы / ссылки о том, как написать хорошо структурированный бэкэнд, используя хранимые процедуры и пользовательские типы? Обычно у меня был бы деловой уровень, где все это происходило бы, но то, что хочет работодатель, получает работодатель и так далее.

Answer 1

Вы можете по-прежнему иметь бизнес-уровень - просто вы пишете его на PL / SQL, а не на каком-либо другом языке.

Типичный бизнес-уровень PL / SQL будет использовать пакеты для каждой основной области функциональности с соответствующими процедурами и функциями, например.

create package employees_pkg as
    procedure hire_employee (p_id integer, p_name varchar2,
                             p_start_date date, ...);
    procedure terminate_employee (p_id integer, p_end_date date);
    ...
end;

Эти пакеты могут выполнять DML непосредственно в отношении таблиц, хотя некоторые (не я) рекомендовали бы слой "API таблицы" ниже этого, чтобы employee_pkg.terminate_employee вызывал "employee_tapi.update (...)" вместо "UPDATE сотрудники ... ", что мне кажется бессмысленным.

У пользовательских типов есть свое применение, но я бы не стал зацикливаться на попытках создать OO-слой в PL / SQL.

Вы не говорите, из чего построено ваше клиентское приложение, но Oracle Application Express будет отличным выбором для веб-приложения базы данных Oracle.

Answer 2

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

В любом случае, клиент не ожидает, что вы будете генерировать HTML прямо из базы данных, не так ли?

При этом я работал над гигантским приложением, которое много откладывало (слишком много я бы сказал) на базу данных (не PL / SQL, а Oracle и MSSQL - что означало два набора хранимых процедур - и иногда конкретные таблицы, представления, триггеры и ограничения - поддерживать). Что бы я сказал с общей точки зрения:

• Читать, читать, читать
• Сначала проработайте схему до мелочей (не стесняйтесь разбивать элементы на множество разных таблиц и использовать представления для их объединения и получения более простого интерфейса с вашей базой данных),
• Если пользовательские типы PL / SQL хороши, то скрывайте таблицы / представления верхнего уровня за пользовательскими типами (всегда),
• Подумайте о модульности и «обслуживании» для организации ваших процессов,
• Не пытайтесь быть умным / быстрым с самого начала.

Я имею в виду такую ​​структуру:

• BUSINESS: хранимые процедуры и пользовательские типы
• APPLICATIVE: представления, таблицы, внутренние процедуры, внутренние типы
• ХРАНЕНИЕ: базовая схема (базовые таблицы), триггеры и ограничения (манипулировать с осторожностью)

О, да, и рефакторинг рано. Чем больше приложение, тем сложнее его перемещать, особенно в такую ​​среду.

Конечно, мне не нужно просить вас тестировать рано;)

Answer 3

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

PL / SQL не является языком в том же смысле, что и Python или PHP. Поэтому, что бы вы ни делали на своем «бизнес-уровне», вы все равно будете делать то же самое. Разница возникнет в DAL (у вас есть, не так ли?). Вместо SQL вы будете использовать PL / SQL как вызовы функций с аргументами. Он становится вашим ORM, если хотите, но построен в базе данных (и, возможно, более функционально ориентирован, чем объектно-ориентирован).