Re: Are stored procedures/triggers common in your industry - Mailing list pgsql-general
Agree with the comment on python, et al. I meant lock in within the context of Oracle PL/SQL.
Actually, the point of Postgres support for all the languages you mentioned is interesting in that such mitigates the lockin argument if the DB used is. Postgres . Another reason to use Postgres, among all the other reasons we know.
Architecturally speaking, using stored procs is a an elegant solution that provides proper abstraction for the Data Layer API, effectively separating the data access and security layers (stored proc design considerations) from the data model and storage considerations. This API type of layer provided by procs is more closely aligned with how one thinks about microservices.
Secondly, it will generally be runtime faster as it avoids the critical network round trips that take up those precious milliseconds.
On Wed, Apr 20, 2022 at 3:54 PM Guyren Howe <guyren@gmail.com> wrote:
On Apr 20, 2022, at 13:43 , Alex Aquino <alex@efficiencygeek.com> wrote:You can write your stored procedures and triggers in:Agree on the lock in comment, however, can't we say that of anything one is dependent on in the tech stack, whether that be at the java vs javascript vs python, or now aws vs azure vs gcp?Have always wondered that lock in concern seems to be only mentioned in light of dbs, but not any other piece of the tech stack.On Wed, Apr 20, 2022 at 3:31 PM Ravi Krishna <srkrishna@vivaldi.net> wrote:>I've really only ever worked in web development. 90+% of web
>developers regard doing anything at all clever in the database with suspicion.One common argument they use is that if you write your business logic in stored procedure, you are locked to that database since stored procedure languages are pretty much vendor locked.
TBH when one sees tens of thousands of Oracle PL/SQL code, there is some truth in this.
- python- perl- Java- R- Javascrpt- Rust- C- … others (scheme, …)How is this lock-in, again?
pgsql-general by date: