[ashinybrowncoat]

So don't use the database for what it is intended because...it might be harder? I very much disagree with this article. It is not so simple to just declare no business logic in the DB when the DB schema itself IS a BIG part of the business logic. When working with data, the best place to work with the data is where it is stored, not pulled out and put back in. And your app is more likely to be replaced long before the data and/or database is. Stop treating the database like a black box and use it for what it is intended.

[Shorel]

I think the problem here is one of total disregard of any performance issues.

To me this is the kind of people who only write SQL through ORM, suffers constantly from the N+1 problem, and say that RDMS are slow compared to key/value stores.

I wonder how good can ChatGPT become for SQL and if it can replace these people xD

[Clubber]

>So don't use the database for what it is intended because

The database is intended to store and retrieve data.

[ashinybrowncoat]

You missed the word maintain and is a very important point. If I can only maintain the data through an app and not directly in the database then the database is nothing more than a card file. Why not use the database features it was intended to provide? The app will be gone long before the data. Always. The next app will need to reproduce the previous apps logic. What if that was already done? It is better to have a mixz used judiciously, than to just consider the database only for storing and retrieving of data. What a wate of resources to not use those things!

[Clubber]

Data integrity is maintained through FK, unique indexes, proper modeling, etc.

Also, an RMDBS is hard to scale horizontally, so the more CPU tasks you put on it, the sooner you will hit a bottleneck that is not easy to get out of. A application layer, if designed properly can scale a lot more.

>The app will be gone long before the data.

When this ever happens, it happens rarely, and the situation is the data enters a read-only state in my experience and happens during sunsetting. Most of the time, if a new system is required, a migration occurs to a new schema that the new app supports.

[ashinybrowncoat]

We use a mix of SQL and NoSQL databases for different and specific purposes. Your suggestion is to do the data manipulation outside of the database which typically means pulling data sets out, doing something with them, and then putting them back in. That will never be more efficient than just doing it in the database. Our SQL databases are actually scaled horizontally using read replicas since writes are much less frequent than reads and we can easily add/remove instances as demand grows and shrinks. IMO, it wasn't any more difficult to scale out our databases than it would have been to implement any other K8 (application or DB).

[tstrimple]

> Your suggestion is to do the data manipulation outside of the database which typically means pulling data sets out, doing something with them, and then putting them back in.

It doesn't mean that at all. You can still leverage SQL to get amazing performance for queries and mutations across large datasets without burying that in a stored procedure. Yes it's generally a bad idea to pull thousands of records across the network and into memory to manipulate them before putting them back. But that's a false dichotomy.