Just do it in the database.

GOD I HATE YOU ALL !!

On the other hand, the fact that business logic is more tightly connected to the webserver (which handles limited amounts of data) than it is to the database (which handles potentially very large amounts of data) is weird. The entire reason we have SQL and ORMs and all that oversized infrastructure is that the application server doesn't have the data and the database server doesn't have the logic but the connection between them is very narrow so neither of them has enough information to work efficiently on their own and they require endless tinkering and thousands of lines of heuristics to even approach efficiency.

Basically, the ideal backend performance-wise can construct itself in SQL and send the result for execution to the database server. This allows the DBMS to optimise and only send the necessary info back to the API server.

@lbfalvy pretty sure I wasn’t complaining about ordinary db processing. This is the “create a cursor, loop through and use extensions to call an api to get the missing data, do the calculation, then return it to the app layer”. Looping in app, easy and efficient, looping in a db without recursion, not so much.

Anyone knows that Facebook is still on MYSQL 5.6...

They've their own fork of MySQL and are stuck in migration limbo. :)

@atrabilious

Yes... Or the dreaded "let's make an bukkake of 4-5 Apps, each a different language / version, one shared database and use data transformation (e.g. money conversion, multiplication, ...) in apps and database.

Nothing more fun to find out what is calculated by whom, which types are involved, which risks exist (e.g. precision loss, overflow, ...) and how to hot glue this mess together.

@atrabilious I wasn't arguing either, I was just noting that from the perspective of efficiency, doing as much as you can with the database is not only better but universally accepted as standard.