3 ms·

On the [Simplify: move code into databases](https://sive.rs/pg https://sive.rs/pg), has anyone actually tried this? My instinct is that the output won't be sim

On the [Simplify: move code into databases](https://sive.rs/pg https://sive.rs/pg), has anyone actually tried this? My instinct is that the output won't be simpler at all, but a big twisty web of varying parts and competing use cases, all extremely hard to discover. To me, having two things that do something distinct is simpler, and ironically, Rich Hickey says this exact thing in Simplicity Matters, which is quoted in the article.

jjice 3y ago
> To me, having two things that do something distinct is simpler I completely agree. Inside the DB, it's hard to argue about performance benefits in a lot of situations. That said, debugging, testing, and developing are so much harder. I love to have a well written bit of code that I can integration test as well as mock up and use for unit tests with other components of my application. It's much trickier to do that in the DB. Sometimes it is a lot more performant, and that's a situation you may want to consider moving towards, but I would try to stay away from it for as long as the performance gain isn't huge.
wg0 3y ago
One caveat is when you have to upgrade across major database versions. The more your application utilises these features, the more you're likely to hit when next major version upgrade has to happen. Not that major database versions are any simpler even if you just stick to CRUD for databases.
- KronisLV 3y ago
  > Not that major database versions are any simpler even if you just stick to CRUD for databases. I mean, even LTS versions have EOL dates, so even at the least frequent, you'll need to do upgrades around every 5 years or so.
- cpursley 3y ago
  This is also true of upgrading dependencies in the application layer.
Kinrany 3y ago
Having two distinct things doesn't mean placing them in separate processes. Or we'd all be writing Erlang by now
- cpursley 3y ago
  We kinda all are writing Erlang now, just inferior and overly complex abstractions ("serverless", K8s, etc).

jjice 3y ago

> To me, having two things that do something distinct is simpler I completely agree. Inside the DB, it's hard to argue about performance benefits in a lot of situations. That said, debugging, testing, and developing are so much harder. I love to have a well written bit of code that I can integration test as well as mock up and use for unit tests with other components of my application. It's much trickier to do that in the DB. Sometimes it is a lot more performant, and that's a situation you may want to consider moving towards, but I would try to stay away from it for as long as the performance gain isn't huge.

wg0 3y ago

One caveat is when you have to upgrade across major database versions. The more your application utilises these features, the more you're likely to hit when next major version upgrade has to happen. Not that major database versions are any simpler even if you just stick to CRUD for databases.

KronisLV 3y ago
> Not that major database versions are any simpler even if you just stick to CRUD for databases. I mean, even LTS versions have EOL dates, so even at the least frequent, you'll need to do upgrades around every 5 years or so.
cpursley 3y ago
This is also true of upgrading dependencies in the application layer.

Kinrany 3y ago

Having two distinct things doesn't mean placing them in separate processes. Or we'd all be writing Erlang by now

cpursley 3y ago
We kinda all are writing Erlang now, just inferior and overly complex abstractions ("serverless", K8s, etc).