只有一次我在PostgreSQL中遇到記憶體問題，那是因為我在數組和json中使用了太多數據

可能是因为不像应用程序代码那样容易进行适当的测试。而且调试要困难得多。

顺便说一下，促使文章中该部分的具体情况是一组递归函数，我们用来将不规则的图结构（不适合CTE）反规范化为一个JSON块，发送到另一个数据存储。99%的时间里没有问题，但在负载较重和复杂子图的情况下，这些递归调用栈导致了复制延迟。将遍历逻辑移到应用程序中，只向Postgres发送SQL查询（我们不使用ORM）消除了延迟。应用程序和数据库之间的往返时间只有几毫秒，而且这也不是面向用户的逻辑，因此在这种情况下额外的延迟不是问题。可能这里的根本问题是模式设计不佳，但有时候你只能使用现有的东西。另外，Reddit上的一个评论者指出，如果我们使用纯SQL技巧的话…

我完全反对使用触发器来实现业务逻辑，但发现存储过程可以很好地封装一些应用程序/业务逻辑。我有几个应用程序访问同一个数据库，将逻辑放在数据库中可以避免在客户端重复它。大多数关于可调试性的评论都是无稽之谈。这只是不同而已，有一些优缺点。一个简单的例子——如果你在生产环境中发现了一个错误，你不会去附加调试器到生产应用程序上。但你可以绝对地打开一个只读连接到数据库，开始运行查询，调用函数等等。如果你能设计你的函数来区分纯只读函数和有副作用的函数，这会有所帮助，但即使没有这样做，你仍然可以进行调试。