Re: Are stored procedures/triggers common in your industry

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(at)gmail(dot)com> wrote:

> On Apr 20, 2022, at 13:43 , Alex Aquino <alex(at)efficiencygeek(dot)com> wrote:
>
>
> 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(at)vivaldi(dot)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.
>>
> You can write your stored procedures and triggers in:
> - python
> - perl
> - Java
> - R
> - Javascrpt
> - Rust
> - C
> - … others (scheme, …)
>
> How is this lock-in, again?
>