3 ms·

> How did you decide which bits of business logic would live in the database as opposed to at the application layer(s)? Not the previous poster but... I would

by jmull 3y ago

> How did you decide which bits of business logic would live in the database as opposed to at the application layer(s)? Not the previous poster but... I would think of it as an application layer that is running at the database. It would make the most sense for logic that is closely coupled to data access... exactly what that is depends on your app. Low-level access control policies... maybe you need to dig data out of a bunch of tables and turn it in to a hierarchy based on complicated user prefs also stored in the database... Or the opposite where you have complex data coming in that needs to be written to a bunch of tables, especially when there's back and forth. I don't think very many should try to put their whole app in there. Database compute tends to get expensive and complicated to scale, so stuffing things in there just because you can might run in to trouble. Not to mention (except for SQLite) the runtime environment is seriously constrained in all kinds of ways. The previous post mentions triggers but I don't know what those have to do with this. The chance that triggers are right solution to any given problem is approximately 0% in my experience.

sodapopcan 3y ago
I think this is essentially what I meant? In any event, I responded a little clearer but ya, shaping data and moving it around is a big thing I feel should be done in the DB. Having spent time in the rails world for several years, I worked with a lot of people who didn't want to do ANYTHING at the DB level. Like, obviously they'd do joins and things ActiveRecord could do easily, but they'd be fine pulling in a bunch of rows and reducing them in Ruby. That drove me nuts. I'm not an optimization junky at all but I do not like that in the slightest. Not only is it wasteful and slower, in my experience it's also more error prone.
- JohnBooty 3y ago
  pulling in a bunch of rows and reducing them in Ruby [...] Not only is it wasteful and slower, in my experience it's also more error prone. Yeah. A lot of problems happen for one of two reasons. The application developers don't wrap the whole thing in a transaction, and open themselves up to consistency problems. Or they do wrap a bunch of database round trips up in a transaction and open themselves up to contention issues, deadlocks, etc. In both cases, those problems generally never show up in local or test environments. Only in prod... under load.

by jmull 3y ago

sodapopcan 3y ago

I think this is essentially what I meant? In any event, I responded a little clearer but ya, shaping data and moving it around is a big thing I feel should be done in the DB. Having spent time in the rails world for several years, I worked with a lot of people who didn't want to do ANYTHING at the DB level. Like, obviously they'd do joins and things ActiveRecord could do easily, but they'd be fine pulling in a bunch of rows and reducing them in Ruby. That drove me nuts. I'm not an optimization junky at all but I do not like that in the slightest. Not only is it wasteful and slower, in my experience it's also more error prone.

JohnBooty 3y ago
pulling in a bunch of rows and reducing them in Ruby [...] Not only is it wasteful and slower, in my experience it's also more error prone. Yeah. A lot of problems happen for one of two reasons. The application developers don't wrap the whole thing in a transaction, and open themselves up to consistency problems. Or they do wrap a bunch of database round trips up in a transaction and open themselves up to contention issues, deadlocks, etc. In both cases, those problems generally never show up in local or test environments. Only in prod... under load.