【问题标题】:What to choose: Stored Procedure of Dynamic SQL in Postgresql选择什么:Postgresql 中动态 SQL 的存储过程
【发布时间】:2016-06-28 07:37:51
【问题描述】:

这是一个 Postgres 特定的问题。我正处于经典设计情况的中间,我必须决定是使用存储过程还是动态 SQL(准备好的语句)。我已经阅读了很多关于相同内容的博客,并得出结论,在当前高级数据库系统的实现中,没有任何特定的属性可以相互权衡。 因此我的问题是 Postgresql 特定的。

What I want to ask is, are there advantages or disadvantages of using Stored Procedures in Postgres? 

关于我的设计的更多信息:由于我们正在使用 Postgres 特定的函数(如 width_bucket)并依赖 Postgres 提供的各种其他东西(如 Partitioning 和 Inheritance),因此我们将来不太可能切换到任何其他数据库提供程序。我们的查询将是复杂的查询,涉及从实时/非实时数据构建图形和报告。 还会建立一些分析。此外,我们还将计划对数据库进行分片和分区。 我想要关于使用存储过程和我上面描述的系统和环境类型的观点,特定于 Postgresql。 我还想了解 Postgres 中查询优化和执行的工作原理。

【问题讨论】:

  • 两者都用?双方各有利弊,都不是灵丹妙药。我从来没有在一个不需要存储过程的应用程序上工作过,但是通过 id 选择对于存储过程来说完全是多余的......

标签: database postgresql stored-procedures


【解决方案1】:

好的,所以您的问题是是否在客户端创建 sql 并将其发送到服务器,而不是存储过程。请注意,通常如果您使用存储过程,您仍然必须创建调用它们的 sql,因此它不是纯粹的非此即彼的。所以这是关于关系接口与存储过程的对比。

另外值得注意的是,一个关键问题是这是一个应用程序拥有的数据库还是许多应用程序可能使用的数据库。在前者中,您可能不担心封装,但在后者中,您希望将数据库视为具有服务接口。

因此,如果它是“我的应用程序有一个数据库,并且所有材料使用都通过我的应用程序”,那么请针对基础表使用动态 SQL。

但是,如果您的数据库有一个或多个应用程序,您需要确保可以更改数据库结构而不会破坏任何或所有数据库。这通常意味着将访问封装在某种抽象接口后面。这可以是 VIEW 或存储过程的使用。

视图的优点是可以直接在 SQL 中操作,并且非常灵活。这允许对它们背后的数据进行广泛的检索(以及一些工作存储)。应用程序不需要知道数据是如何物理存储的,只需要知道如何访问它。

存储过程具有相同的封装优势,但提供的接口更加有限。它们还有一个问题,通常人们以需要固定数量参数的方式使用它们,因此添加参数需要密切协调数据库和应用程序的更新(Oracle 的基于修订的版本是解决这个问题的方法,但 PostgreSQL 没有相似的)。但是,只需做一些工作,就可以在运行时发现参数并适当地处理它们。

总而言之,这是一个宽泛的问题,细节比笼统更重要。

【讨论】:

  • 你能给我指点一下我应该如何评估 Postgres 的各种东西吗?
  • 当您遇到特定于 PostgreSQL 的问题时,您将能够识别它们。我的建议是先从一般情况开始,然后在进行过程中了解有关 db 的更多信息。
  • 另外,我要指出的是,如果您没有正确掌握数据库基础,那么 PostgreSQL 的超高级功能很容易被滥用。大多数高级功能在您需要时都很棒,但对于奇异问题的奇异解决方案
猜你喜欢
  • 1970-01-01
  • 2014-12-07
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-02-27
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多