5 ms·

> most of the business logic of a system can be in the database The problem of this approach is the tooling and lock-in. If databases had first-class versioni

by toyg 4y ago

> most of the business logic of a system can be in the database The problem of this approach is the tooling and lock-in. If databases had first-class versioning support for their code objects (which could easily interoperate with git), testing automation, and a parvence of standardization across the industry, then a lot of people would be very happy to work with that model. But they don't.

tracker1 4y ago
Came in to say pretty much the same thing. Discoverability is a huge issue... and even if you do things in a way that lends itself to that, it gets really clunky really quickly.
CuriouslyC 4y ago
While the tooling could definitely be better, a lot of those issues aren't so problematic if you just use Postgres. Use a migration tool and store the migrations in git, use a tool like Zapatos to provide typing for your queries at the application layer, support multiple versions of stored procedures using schemas with a defined search order and test your procedures using pgTap. Postgres-as-a-platform is definitely a new architectural trend, but because of companies like Supabase it's maturing quickly, and there are so many benefits to it when executed properly.
yamtaddle 4y ago
> The problem of this approach is the tooling and lock-in. I've seen a program rewritten or heavily refactored on top of an existing database more times than I've seen the database swapped on an app that had reached production (which I've seen zero times). Consequently, I have regard remaining "database agnostic" as having very little worth. If you pick a DB with a bunch of great features that can save you time, improve performance, and improve data integrity—use those features! Plus, if you find yourself in that rewriting-or-heavily-refactoring job that I've seen a few times, your favorite person in the whole world will be whoever put all those annoying constraints and triggers and such in the DB itself. It'll make the operation far easier and safer.
iamacyborg 4y ago
I may be misunderstanding here because I’m not a dev and have only a cursory level of experience doing some basic programming or sql but is this not what dbt allows?

by toyg 4y ago

tracker1 4y ago

Came in to say pretty much the same thing. Discoverability is a huge issue... and even if you do things in a way that lends itself to that, it gets really clunky really quickly.

CuriouslyC 4y ago

While the tooling could definitely be better, a lot of those issues aren't so problematic if you just use Postgres. Use a migration tool and store the migrations in git, use a tool like Zapatos to provide typing for your queries at the application layer, support multiple versions of stored procedures using schemas with a defined search order and test your procedures using pgTap. Postgres-as-a-platform is definitely a new architectural trend, but because of companies like Supabase it's maturing quickly, and there are so many benefits to it when executed properly.

yamtaddle 4y ago

> The problem of this approach is the tooling and lock-in. I've seen a program rewritten or heavily refactored on top of an existing database more times than I've seen the database swapped on an app that had reached production (which I've seen zero times). Consequently, I have regard remaining "database agnostic" as having very little worth. If you pick a DB with a bunch of great features that can save you time, improve performance, and improve data integrity—use those features! Plus, if you find yourself in that rewriting-or-heavily-refactoring job that I've seen a few times, your favorite person in the whole world will be whoever put all those annoying constraints and triggers and such in the DB itself. It'll make the operation far easier and safer.

iamacyborg 4y ago

I may be misunderstanding here because I’m not a dev and have only a cursory level of experience doing some basic programming or sql but is this not what dbt allows?