Fork me on GitHub
#sql
<
2020-10-09
>
Ludwig17:10:55

Hi, what is the general consensus in clojure world about having business logic in the database, assuming that the db vendor won't change?

seancorfield17:10:25

I'm not sure about "general consensus" but I try very hard to avoid having business logic in the database because of the difficulty of tracking changes/versioning since what's in the DB is "outside the code".

👍 3
☝️ 3
seancorfield17:10:26

(I know you can version the SQL migrations that add such things but, for me, having business logic not all in one place is an inconvenience that I do not accept lightly)

lukasz17:10:39

Depends on what the business logic is - some things like a column type could be considered as such (e.g. storing phone number as long 😉 ). Agreed with @seancorfield though - things like triggers and complicated behavior governed by foreign key constraints tends to backfire at some point. YMMV. We use PG's triggers very sparingly but sometimes there's just no other way of doing things.

dharrigan17:10:22

I use a few triggers and functions in my database - not much, but where it makes sense

dharrigan17:10:44

(and that's postgresql)

seancorfield17:10:52

(I will use triggers occasionally but pretty much only for timestamp updates on row updates)

dominicm18:10:06

There's a movement using postgres row security and such so that most of your application is on your database.