3 ms·
> Yes we CAN do that but why do that it's 15 lines of SQL and 5 seconds compute -- instead of a new microservice or whatever and some minutes of compute. This
by bb88 4y ago
> Yes we CAN do that but why do that it's 15 lines of SQL and 5 seconds compute -- instead of a new microservice or whatever and some minutes of compute.
This works until your database falls over in production. Recently someone started appending to a json field type over and over in our production database. And then on some queries, postgres crashed due to lack of memory. The fix was to remove the field and code that constantly appended to it, and do something else.
No, the database should not be the answer to all your data problems. Yes a microservice may be the best answer. But for structured data and queries that can run with normal amounts of memory the standard SQL DB is fine.
- mike_hock 4y ago> No, the database should not be the answer to all your data problems. Yes a microservice may be the best answer. Or to put it another way: No, microservices should not be the answer to all your data problems. Yes, using the DB may be the best answer.
- ttfkam 4y ago> Recently someone started appending to a json field type over and over in our production database. And then on some queries, postgres crashed due to lack of memory. The fix was to remove the field and code that constantly appended to it, and do something else. So your choices are doing something manifestly non-optimal in the database in violation of best practices or not use the database for non-trivial business logic? Sounds like a false dichotomy to me. Maybe just find a better solution? I mean, if someone writes an O(n^3) algorithm in Python, is the solution to use a better strategy or to swear off Python for anything non-trivial?