Hacker News Reader

Comment by ashinybrowncoat | Hacker News Reader

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!

View on HN

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.

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).

> 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.

Reply on news.ycombinator.com