Question

对不起，如果这是一个愚蠢的问题。我已经离开游戏一段时间了。

我决定是否将PostgresSQL用于网络应用程序。我以前从未使用过它。完成我的研究后，我非常喜欢它为存储函数提供的PGSQL语言。

通常在我的网络应用程序代码中，我保存了一条记录。这包括检查记录是否已经存在 - 如果是，则更新它，否则INSERT新记录。

使用PGSQL - 我可以在一个查询中完成所有这些（而不是MysqL，我很确定你不能）

他们对此有优势吗？或者，此逻辑应保留在Web应用程序层中，而不是数据库中的存储函数。

这是PGSQL中的一个粗略的例子。它只是说明性的，并不意味着安全或良好的代码。

CREATE OR REPLACE FUNCTION save_client(IN strforename character varying, IN strnew character varying)
  RETURNS TABLE(forename character varying, surname character varying) AS
$BODY$

    DECLARE myrec int;

    BEGIN   

        SELECT idx_clients INTO myrec from "Clients" WHERE LOWER("Clients".forename)=$1;


        IF NOT FOUND THEN
            RAISE NOTICE 'No results found.%',myrec;

            INSERT INTO "Clients" (forename,surname) VALUES (strnew,strforename);
        ELSE
            RAISE NOTICE 'YES results found.%',myrec;

            IF myrec NOTNULL THEN
                UPDATE "Clients" SET forename=$2 WHERE idx_clients=myrec;
            END IF;

        END IF;

    END;

$BODY$

Answer 1

我更喜欢将其放在数据库中，原因如下：

它允许您将数据库封装在API后面。您甚至可以发现您的API可被发现（请参阅http://ledgersmbdev.blogspot.com上的一些帖子，了解一种方法），以便应用程序可以在运行时发现调用语法。封装有助于确保多个应用程序可以安全地访问同一个数据库，因为rdbms最终成为具有良好定义的API的服务器。
它实质上确保了一种可用于创建更稳定接口的依赖性反转。
它允许您在很大程度上将SQL保留在应用程序文件之外（因为调用接口本身可以抽象为单个API）。
更好地控制交易逻辑和性能（但见下文）

据说有一些陷阱需要注意：

存储过程是最易维护的，只要它们是一个具有一些次要支持逻辑的大型查询。
小心锁
不要混合事务和非事务逻辑。事务逻辑属于db。任何非交易的东西都属于它。例如，不要从存储过程发送电子邮件。不要暂停数据库事务以尝试与用户建立网络连接，询问他或她是否要继续。不要将这些链接到直接来自存储过程的真实世界影响的脚本中.....
小心合同。人们在存储过程开发中遇到的一个重大问题与模式更改有关。您添加了一个需要收集的其他列，而不是代码更改的两个位置，您至少有三个。这是我非常强调可发现性的一个原因，因为这使您可以构建更灵活的合同，并仅在需要更改的地方更改代码。换句话说，事情可能会优雅地失败。

我说这大部分都是作为数万行PostgreSQL存储过程的作者，大多数是在sql和pl / pgsql中。存储过程带来了管理上的挑战，但是一旦你驯服它们，它们就值得付出努力。

Answer 2

我通常宁愿在应用程序中使用这种功能，原因如下：

服务器负载无论如何，您的数据库服务器通常都会负载很重，应用程序服务器通常不那么重要。
技术它使您的实施数据库不可知，所以如果您以后决定转移到MySQL或Oracle，您将失去功能或不得不重新设计它们。
可维护性如果其他人不得不将自己的代码与自己区分开来，那么将代码抽象到数据库中将不那么直观。他们会花时间寻找那些不存在的功能。

您的主要考虑因素可能与我的不同。我希望在数据库中完成这一切会有一些性能提升，因此可能会考虑到它，但我总是尽量使我的实现尽可能地与技术无关。

数据库逻辑VS应用逻辑

2 个答案: