4 ms·

I am not sure i understand your comment also :) My point was that people (read web devs) treat databases (postgres) as only data stores, put in data, get data o

I am not sure i understand your comment also :) My point was that people (read web devs) treat databases (postgres) as only data stores, put in data, get data out, and they are so much more. Sure not anything goes into the db, but if it's a bit of logic that relates only to the data (who can access it, who can change it and in what way), most likely it belongs in the database. PS: but let's not derail this thread with debates on where business logic should go :)

grzm 10y ago
I think I agree with you that there are some things that belong in the database. For example, anything I can do in the database to ensure data integrity (without unduly affecting performance), I'll put there (data types, constraints, triggers, functions which encapsulate transactions). Similarly with access privileges. My initial comment was in response to these statements: I have a friend who likes to do as much as possible with pgsql and I'm often surprised at how well it performs for the things he uses it for. I understood you to read this as putting business logic in the database (indicated by the And yet) in your comment: And yet i hear day after day, don't put business logic in the db I read the initial comment by 'fapjacks as meaning using Postgres whenever appropriate, as opposed to doing everything one could with Postgres in Postgres. Not a big deal at all. I saw a potential misunderstanding and attempted to clarify. PS: Of course, business logic should go where I put it, right? ;)
- ruslan_talpa 10y ago
  You are right in both cases, yes i read that comment like you described and yes that is probably not what fapjacks meant. As for the beginning of your comment, i am 100% with you. The problem is that the cases you describe (integrity,access,reports on data) are most of the time what the entire application does (we are all just doing CRUD and all that ...) and instead seeing that for what it is (let's call it DataLogic) people are all to often calling it Business logic, and the moment they put that label on it their brain automatically (after years of conditioning) does not even begin to consider the database as the appropriate place for that type of logic.

grzm 10y ago

I think I agree with you that there are some things that belong in the database. For example, anything I can do in the database to ensure data integrity (without unduly affecting performance), I'll put there (data types, constraints, triggers, functions which encapsulate transactions). Similarly with access privileges. My initial comment was in response to these statements: I have a friend who likes to do as much as possible with pgsql and I'm often surprised at how well it performs for the things he uses it for. I understood you to read this as putting business logic in the database (indicated by the And yet) in your comment: And yet i hear day after day, don't put business logic in the db I read the initial comment by 'fapjacks as meaning using Postgres whenever appropriate, as opposed to doing everything one could with Postgres in Postgres. Not a big deal at all. I saw a potential misunderstanding and attempted to clarify. PS: Of course, business logic should go where I put it, right? ;)

ruslan_talpa 10y ago
You are right in both cases, yes i read that comment like you described and yes that is probably not what fapjacks meant. As for the beginning of your comment, i am 100% with you. The problem is that the cases you describe (integrity,access,reports on data) are most of the time what the entire application does (we are all just doing CRUD and all that ...) and instead seeing that for what it is (let's call it DataLogic) people are all to often calling it Business logic, and the moment they put that label on it their brain automatically (after years of conditioning) does not even begin to consider the database as the appropriate place for that type of logic.