Зачем использовать хранимую процедуру вместо запроса непосредственно на db?

Question

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

select * from some_table, update some_table, etc. 

Мы должны использовать хранимую процедуру, чтобы сделать запросы.

Что касается моего последнего вопроса здесь: Postgres pl/pgsql ERROR: column "column_name" does not exist

Я задаюсь вопросом, мы должны создать хранимую процедуру для каждой таблицы, или в состоянии? Есть ли способ более эффективно создавать хранимые процедуры?

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

и простите за мой плохой английский ..: D

Answer 1

Некоторые причины использовать хранимые процедуры являются:

• Они предположительно прошли некоторое тестирование на убедитесь, что они делают , чтобы не нарушать правила бизнеса, а также некоторую оптимизацию для производительности.
• Они обеспечивают согласованность результатов. Каждый раз, когда вас спрашивают , выполняйте задачу X, вы запускаете связанную с хранимой процедурой задачу X. Если вы пишете запрос, вы не можете писать его одинаково каждый раз; , может быть, однажды вы забудете что-то глупое, как форсирование текста до того же случая перед сравнением, и что-то пропущено.
• Они начинают писать несколько длиннее, чем просто запрос, но , выполняющий эту хранимую процедуру, занимает меньше времени, чем запись запроса . Запустите его достаточно времени, и становится более эффективным, чтобы написал хранимую процедуру.
• Они уменьшают или устраняют необходимость знать отношения основных таблиц.
• Вы можете предоставить разрешения для выполнения хранимых процедур (с security definer), но запретить разрешения для базовых таблиц.
• Программисты (если вы разделяете администраторов баз данных и программистов) могут быть предоставлены API , и это все, что им нужно знать. До тех пор, пока вы поддерживаете API при изменении базы данных, вы можете внести необходимые изменения в базовые отношения, не нарушая их программное обеспечение; действительно, вам даже не нужно знать, что они сделали с вашим API.

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

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

CREATE OR REPLACE FUNCTION aSchema.aProcedure (
    IN var1  text, 
    IN var2  text, 
OUT col1  text, 
OUT col2  text 
) 
    RETURNS setof record 
    LANGUAGE plpgsql 
    VOLATILE 
    CALLED ON NULL INPUT 
    SECURITY DEFINER 
    SET search_path = aSchema, pg_temp 
    AS $body$ 
     BEGIN 
      RETURN QUERY /*the query you would have written anyway*/; 
     END; 
    $body$; 
GRANT EXECUTE ON FUNCTION aSchema.aProcedure(text, text) TO public; 

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

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