#plsql #oracle10g
Вопрос:
как правило, лучше скрывать однорядные выборки внутри функции, поэтому вместо:
BEGIN
SELECT name
INTO l_name
FROM mytable
WHERE primary_key = id_primary_key;
было бы лучше разработать
PACKAGE mypackage
IS
FUNCTION fnc_name (id_primary_key IN mytable.primary_key%TYPE)
RETURN mytable.name%TYPE;
и выполнение
BEGIN
l_name := mypackage.fnc_name (id_primary_key);
Но как насчет обновления?
Я имею в виду, если я решу разработать одно и то же решение для обновления, но в этом случае каждый раз, когда мне нужно обновлять только несколько столбцов таблицы, как бы вы разработали такой API?
Oracle версии 10g
Спасибо!
Марк
Ответ №1:
Вы начинаете разрабатывать «табличный API» или «TAPI». Это проблематично по причине, о которой вы упомянули: если процедура обновления TAPI обновляет все 20 столбцов таблицы из 20 параметров, но в конкретном случае вам нужно обновить только 3 столбца, как вы должны это назвать? Один из способов-просто передать все 20 значений, даже если вы не меняете большинство из них. Другой способ-придать каждому параметру «забавное» значение по умолчанию, как CHR(0)
и при обновлении API, как:
UPDATE mytable
SET column1 = CASE WHEN p_column1 = CHR(0) THEN column1 ELSE p_column1 END,
...
Другой (я бы сказал, лучший) подход-это «API транзакций» или XAPI. Здесь вы создаете отдельную процедуру для каждой бизнес-транзакции, для которой может потребоваться обновить таблицу. Например:
PROCEDURE terminate_employee
( p_empid INTEGER
, p_termination_date DATE
, p_termination_reason VARCHAR2
);
В этой процедуре будет использоваться простая инструкция SQL update для обновления 3 столбцов, которые необходимо обновить при увольнении сотрудника.
Некоторые сказали бы, что SQL-это API для базы данных!
Комментарии:
1. «Как правило, лучше скрывать однорядные выборки внутри функции»; Кто говорит? Почему? ИМХО, я совершенно доволен тем, что одна таблица извлекается в соответствии с остальным кодом, это простые операторы. То, что я хочу скрыть за границами функций, — это длинные сложные запросы и/или очень сложная обработка.
2. @Страхующий Ну, только не я!