Earlier quoted context omitted.
This is definitely true on both ends. At a previous company, the tech influencers believed in the archaic "do everything in the database." While we were technically using the .Net stack, we weren't allowed to do any actual business logic in C#. Instead it had to all be done in MS-SQL procedures (or at least at much as possible with very little CLR glue). Similarly at my current company, we had a product were the init…
Can you explain why you feel that "do everything in the database" is archaic? A lot of logic (especially authentication logic) can be put in the database only. Not to mention that I won't trust anything that only has application level security, and nothing at database level to check/limit it.
1. it doesn't work well with source control
2. deployments, rollback, replication, synchornization - they don't work very well with db procedures
3. unless you connect directly to the db, then you must have some logic on the serverside, usually you end up replicating logic from the db to the serverside
4. Databases languages (even advanced ones like PL/SQL) are not expressive enough
5.It's much easier to scale out the server then the database (and if you are using Oracle/Sql-server etc... also cheaper), and you don't want your database's cpu to be clogged with logic code execution
6.Unit testing (or any testing) is extremely difficult
7.Debugging is hard and convoluted (also it doesn't usually work inside your IDE)
and a whole lot more.
Nothing is absolute or completely obsolete, but it is considered a bad practice for a long time by most industry professionals.
As far as I know the most popular article about it is:
https://blog.codinghorror.com/who-needs-stored-procedures-an...