| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | hmidi slim <hmidi(dot)slim2(at)gmail(dot)com> |
| Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: decompose big queries |
| Date: | 2018-04-05 22:51:10 |
| Message-ID: | CAKFQuwZfJL=WfTK_9wO4gNbY=6KgX-0_JKnLSVK9XW_ww5N2vQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Thu, Apr 5, 2018 at 3:39 PM, hmidi slim <hmidi(dot)slim2(at)gmail(dot)com> wrote:
> I want to know what are the best practice to use in order to decompose a
> big query which contains so many joins.Is it recommended to use stored
> procedures ? or is there any other solution?
>
Views are another solution.
https://www.postgresql.org/docs/10/static/tutorial-views.html
Though while "building views upon views" is not uncommon, and it does
increase the readability of each individual view, it add update fragility
to the system.
Encapsulating high-level API concepts in functions and then writing queries
within those functions with the benefit of views is one possibility. Your
client access needs and general data model are necessary to choose a
preferred design.
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexandre Arruda | 2018-04-06 00:09:23 | ERROR: found multixact from before relminmxid |
| Previous Message | hmidi slim | 2018-04-05 22:39:06 | decompose big queries |