Php 数据库逻辑与应用程序逻辑

对不起，如果这是一个愚蠢的问题。我已经退出比赛一段时间了

我正在决定是否将PostgresSQL用于web应用程序。我以前从未用过它。 在完成研究之后，我非常喜欢它用于存储函数的PGSQL语言

在我的web应用程序代码中，我经常保存一条记录。这包括检查记录是否已经存在——如果已经存在，则更新它，否则插入新记录

使用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$

---

出于以下几个原因，我通常更愿意在应用程序中使用这种功能：

服务器负载无论如何，您的数据库服务器通常都会处于重载状态，而应用程序服务器通常不会如此

技术它使您的实现数据库不可知，因此，如果您以后决定迁移到MySQL或Oracle，您将不会丢失这些功能或不得不重新设计它们

可维护性如果其他人不得不在自己之外维护代码，那么将代码抽象到数据库中会变得不那么直观。他们会花时间寻找没有的功能

---

你的主要考虑可能与我的不同。我希望在数据库中完成这一切会带来一些性能提升，因此这可能是其中的一个因素，但我总是尽可能保持我的实现与技术无关。

出于以下几个原因，我更愿意将其放在数据库中：

它允许您将数据库封装在API后面。您甚至可以使您的API可发现（请参阅关于一种方法的许多文章），以便应用程序可以在合理的情况下在运行时发现调用语法。同样，封装有助于确保多个应用程序可以安全地访问同一个数据库，因为rdbms最终成为具有定义良好的API的服务器

它本质上确保了一种依赖倒置，您可以使用它来创建更稳定的接口

它在很大程度上允许您将SQL排除在应用程序文件之外（因为调用接口本身可以抽象为单个API）

更好地控制事务逻辑和性能（但请参见下文）

也就是说，有几个陷阱需要注意：

存储过程是最可维护的，因为它们是一个带有一些次要支持逻辑的大型查询

当心锁

不要混合使用事务逻辑和非事务逻辑。事务逻辑属于数据库。任何非事务性的东西都属于它之外。例如，不要从存储过程发送电子邮件。不要暂停数据库事务以尝试与询问用户是否要继续的用户建立网络连接。不要直接从存储过程中将它们挂接到具有真实影响的脚本中

对合同要小心。人们在存储过程开发中遇到的一个大问题与模式更改有关。您添加了一个需要收集的额外列，代码更改的位置不是两个，而是至少有三个。这是我非常强调可发现性的原因之一，因为这允许您构建更灵活的契约，并仅在需要更改的地方更改代码。换言之，事情可能会优雅地失败

---

我说这些的大部分是作为数万行PostgreSQL存储过程的作者，主要是sql和pl/pgsql。存储过程会带来一些管理方面的挑战，但一旦您驯服了它们，这些挑战就非常值得您付出努力。

Sorry@Solarfury请您详细说明一下。你说你宁愿拥有这种功能，但我不确定你指的是哪一种。一般来说，是业务逻辑。我不觉得在我维护或阅读的应用程序中插入一段代码是很直观的，除非是不存在的键，否则更新。我希望这种逻辑会出现在我的应用程序代码中，而不是数据库中。谢谢Soloarfury-Up，直到我发布了这个问题，这就是我是如何做到的。我想知道这是否是普遍的共识？它可能和任何东西一样依赖于应用程序。例如，如果前端应用程序运行在功能较弱的机器上，而数据库运行在功能非常强大的机器上，那么在数据库中执行此操作可能是一种合乎逻辑的方法。正如我所说，我的方法使我的系统数据库不可知，另一方可能会说，他们以数据库为中心的方法使他们的系统编程语言不可知，因此对php或RoR的更改非常快（或者让各种并行程序访问数据）。我不同意服务器加载的想法。事实上，与临时查询相比，存储过程可以更好地控制这一领域。这是一个非常复杂的领域。事实上，正确使用存储过程可以显著降低服务器负载。这是一个有趣的观点，让我重新考虑我自己的观点。@Oshawott为了支持你的立场，我确实认为一个主要的折衷是在一个用于多个数据库的应用程序和一个用于多个应用程序的数据库之间。如果你打算出售你的应用程序，并且希望它在MS SQL、Oracle和MySQL上运行，但你想说所有对数据库的访问都是通过你的应用程序进行的，那么存储过程绝对是应该避免的。我倾向于从一个有支持数据库的大型应用程序的角度来看这个问题。根据我个人的经验，我们已经从MySQL迁移到pgSQL，从memSQL迁移到Oracle，但从未从核心语言转换过，所以我想，传说中的可移植数据库很重要。