[coldtea]

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

There's nothing archaic about that, actually.

It ensures that your domain logic remains DRY and is not repeated for every new application or service that you connect to your data.

[zidad]

I guess it depends on your application. To me having multiple applications accessing the same database logic (or domain) feels very archaic, or at least hard to maintain.

You'll end up with highly coupled application(s) and a schema that is very hard to change and nearly impossible to deploy small changes in continuous deployment scenario's without maintenance windows. In my experience it's hard to maintain high performance and 0 deployment downtime in applications only using SQL databases multiple applications sharing tables/views.

Then there's always additional platforms for specific areas that are just way more hard in a relational database such as journaling (append only data), queuing, (distributed) caching and searching that will scatter your logic outside the database anyway.

I've found it really hard maintaining DRY principles, finding a balance between readability and performance in large SQL based applications without an extremely disciplined team.

[renolc]

Valid point. Sadly, the system I was working on at said company was monolithic, so I don't believe that advantage was being utilized. It does open it up the potential in the future though.

I feel that this could be solved in other ways as well. Such as with microservices to wrap your database and provide endpoints for other services to consume. This is more like how we do it at my current company.