| One reason why I've stopped putting business logic in databases bar rare times is that you tie your business logic in a defined dependency. As someone who works in a team that abstracts the DB layer as a dependency of the specific controller logic there are multiple good reasons to do so but the primary one is that it makes code independent from the specific database you're using. We use filesystem json databases in the developer machine, swappable with in-memory databases that die with the process, which are perfect for unit and integration testing that always get a clean db service, while running a mixture of SQLite and azure cosmos in prod. All the developer interacts with is UserRepo.find or ProductRepo.add or Transaction repo.query without ever having to think about the database it's running against. The best part is that you can still write custom queries for specific environments (e.g. performance reasons) or when you may want specific ways to generate a specific view of your data. Another good reason to do so, is that most people plain suck at interacting with databases, often they do more harm than good, and unless a query is noticeably slow I'd rather have them work with a predefined sets of primitive operations. But in general, this is hardly ever needed. Acid transactions are probably the only exception to the rule before, but even then you can hide the details and need to touch it. |