为什么使用存储过程而不是直接查询数据库？

Question

我的公司做新的政策，因为我的公司将有一些国际标准的认证。该策略是，DBA不允许直接查询数据库，例如：

select * from some_table, update some_table, etc. 

我们必须使用存储过程来执行查询。

关于我在这里的最后一个问题：Postgres pl/pgsql ERROR: column "column_name" does not exist

我想知道，我们是否必须为每个表或每个条件创建一个存储过程？有没有更有效地创建存储过程的方法？

谢谢你之前的回答..。

为我糟糕的英语道歉..。:D

Answer 1

使用存储过程的一些原因是：

• --他们想必已经做了一些测试，以确保他们不允许业务规则被破坏，以及对的一些优化--确保结果的一致性。每次您被要求执行任务X时，都会运行与任务X关联的存储过程。如果您编写查询，则可能不会每次都以相同的方式编写；也许有一天，您忘记了一些愚蠢的事情，比如在进行比较之前将文本强制转换为相同的情况，而忽略了一些东西。
  • 开始编写的时间比只编写查询要长一些，但运行该存储过程所花费的时间要比再次编写查询所花费的时间要少。运行足够多的时间，编写存储的procedure.
  • They减少或消除了了解底层表关系的需要，效率就会提高。
  • 您可以授予执行存储过程的权限(使用security definer)，但是拒绝底层tables.
  • Programmers的权限(如果您将DBA和程序员分开)可以提供一个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 (虽然这会增加执行函数的人需要了解函数的工作方式，所以我尽量避免它)，从而使函数更具动态性。

如果“效率较低”来自于函数中包含的附加逻辑，那么与仅仅使用查询进行比较是不公平的，因为该函数正在进行额外的工作。