4 ms·

This is hardly a new opinion. It's also an opinion I've come to completely disagree with.

by pipes 4y ago

sodapopcan 4y ago
"Completely" as in you'd put ALL your business logic in the db, or that you're open to pushing SOME to it? Most? EDIT: It's genuine question. I use views and write a decent amount of business logic as queries (well, in my language's query DSL). It's always bugged me when people do a lot of post-processing for stuff that the db could do faster.
- PKop 4y ago
  There's perhaps an interesting 3rd option aside from full stored procedures vs pure application code transformating data pulled down from database... where the processing and transformation is still handled with SQL, but this code and the interaction with the database resides in application code. So instead of triggers and stored procedures, you have database transactions defined in and called from application code.
doctor_eval 4y ago
I am with you 100%. SQL-style languages like plpgsql are crazy fast and super concise relative to the hurdles of doing it all in a host language. I’m building a moderate sized application right now - and even though I consider myself a Go programmer, 100% of my code is either Svelte, Typescript or pl/pgsql + postgraphile. Not a line of Go to be seen. I mean, the day will come when I need to write some Go code. But I’m so much more productive with plpgsql when it comes to anything within a single db.
- yrashk 4y ago
  Being able to implement a lot of business logic in SQL and pl/pgsql is another of the reasons I started developing Omnigres [1]. My initial motivation was to have something almost self-contained, just one thing to deploy infrastructure-wise. But the more time I spend on it, the more I appreciate how having a single place for all the concerns significantly contributes to simplicity. Surely there are some hurdles to overcome. Some are more technical in nature. Some are more on the side of tooling inadequacy/outdatedness. I am trying to contribute to both with the project. [1] https://omnigr.es/ https://omnigr.es/
  - doctor_eval 4y ago
    Omnigres looks really intriguing! I will check it out when I have more time.

This is hardly a new opinion. It's also an opinion I've come to completely disagree with.

by pipes 4y ago

This is hardly a new opinion. It's also an opinion I've come to completely disagree with.

"Completely" as in you'd put ALL your business logic in the db, or that you're open to pushing SOME to it? Most? EDIT: It's genuine question. I use views and write a decent amount of business logic as queries (well, in my language's query DSL). It's always bugged me when people do a lot of post-processing for stuff that the db could do faster.

PKop 4y ago
There's perhaps an interesting 3rd option aside from full stored procedures vs pure application code transformating data pulled down from database... where the processing and transformation is still handled with SQL, but this code and the interaction with the database resides in application code. So instead of triggers and stored procedures, you have database transactions defined in and called from application code.

doctor_eval 4y ago

I am with you 100%. SQL-style languages like plpgsql are crazy fast and super concise relative to the hurdles of doing it all in a host language. I’m building a moderate sized application right now - and even though I consider myself a Go programmer, 100% of my code is either Svelte, Typescript or pl/pgsql + postgraphile. Not a line of Go to be seen. I mean, the day will come when I need to write some Go code. But I’m so much more productive with plpgsql when it comes to anything within a single db.

yrashk 4y ago
Being able to implement a lot of business logic in SQL and pl/pgsql is another of the reasons I started developing Omnigres [1]. My initial motivation was to have something almost self-contained, just one thing to deploy infrastructure-wise. But the more time I spend on it, the more I appreciate how having a single place for all the concerns significantly contributes to simplicity. Surely there are some hurdles to overcome. Some are more technical in nature. Some are more on the side of tooling inadequacy/outdatedness. I am trying to contribute to both with the project. [1] https://omnigr.es/ https://omnigr.es/
- doctor_eval 4y ago
  Omnigres looks really intriguing! I will check it out when I have more time.