5 ms·
> False. What I said is true. As much as possible is 100% true. There are some things that have to live in the business layer. But as much as possible should be
by prmph 3y ago
> False. What I said is true. As much as possible is 100% true. There are some things that have to live in the business layer. But as much as possible should be pushed to the database. All the "business layer" does is build the correct query.
I think you are wrong, the other commenter is correct. In all my years of engineering, I rarely see a lot of business logic in the database.
Note that we are talking about what the situation _is_, not what it should be. It is an eternal debate as to whether it is better to push as much login into the Db as possible. My own view is that you should use the right tool for the job. Databases, excel at, well, managing data. Regular languages excel at logic.
> Business logic should be extremely thin.
I'm leading a team building a front end to statistical engines, storing metadata in the Db. Are you suggesting we should implement the higher level statistical functions in the Db?
- corethree 3y agoYour talking about the multitudes of architectures that stem from the core model. I'm talking about the core model. Which is crud. The core model of a typical website is mainly updates to central state with little compute. Think nodejs server paired with a typical SQL database. The very reason nodejs exists is based on this core assumption of web: low compute and non blocking high io workflows. You're talking about heavy compute... then that deviates from the core model. With heavy compute it turns more into a queue with workers. That is not the core architecture of the web. It's more of popular and important system that exists in conjunction with the core. That is what your statistical function implies. If your stats function is simple and trivial, then you can indeed possibly achieve orders of magnitude of speed up if you offload that trivial calculation to the database.