postgres中SQL以外的语言

Question

我最近一直在使用PostgreSQL,我认为很酷的一点是你可以使用SQL以外的语言来编写脚本函数等等.但什么时候这实际上有用？

例如,文档说PL/Perl的主要用途是它非常擅长文本操作.但这不应该是应该编入应用程序的更多内容吗？

其次,有没有合理的理由使用不受信任的语言？看起来好像任何用户都可以执行任何操作对生产系统来说都是个坏主意.

PS.如果有人可以使PL/LOLCODE看起来有用,那么奖励积分.

Answer 1

@迈克:这种想法让我很紧张.我多次听说"这应该是无限可移植的",但当问到这个问题时:你真的预见到会有任何移植吗？答案是不.

坚持最低的共同标准可能会严重影响性能,抽象层(ORM,PHP PDO等)的引入也是如此.我的意见是:

• 如果需要支持多个RDBMS,请进行实际评估.例如,如果您正在编写一个开源Web应用程序,那么至少需要支持MySQL和PostgreSQL(如果不是MSSQL和Oracle)
• 评估后,充分利用您决定的平台

而BTW:你将关系与非关系数据库混合在一起(例如,CouchDB 不是一个与Oracle相当的RDBMS),这进一步证明了对可移植性的感知需求被高估了很多倍.

Answer 2

“[文本操作]不应该更多地被编程到应用程序中吗？”

通常，是的。普遍接受的数据库“三层”应用程序设计表明，您的逻辑应该位于客户端和数据库之间的中间层。但是，有时您需要触发器中的一些逻辑或需要对函数进行索引，从而需要将一些代码放入数据库中。在这种情况下，所有常见的“我应该使用哪种语言？” 问题出现了。

如果您只需要一点逻辑，则可能应该使用最可移植的语言（pl/pgSQL）。如果您需要进行一些严肃的编程，那么您最好使用更具表现力的语言（也许是 pl/ruby）。这永远是一个判断。

“有任何正当理由使用不受信任的语言吗？”

如上所述，是的。同样，如果可能的话，将直接文件访问（例如）放入中间层是最好的，但是如果您需要基于触发器来触发事件（可能需要访问中间层无法直接访问的数据），那么您需要不受信任的语言。这并不理想，通常应该避免。而且你肯定需要保护对它的访问。