sql

All things SQL and JDBC...
Vachi 2020-10-09T17:17:55.077100Z

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

seancorfield 2020-10-09T17:20:25.078300Z

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".

👍 1
☝️ 1
seancorfield 2020-10-09T17:21:26.079300Z

(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)

lukasz 2020-10-09T17:41:39.081400Z

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.

dharrigan 2020-10-09T17:45:22.081900Z

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

dharrigan 2020-10-09T17:45:44.082100Z

(and that's postgresql)

seancorfield 2020-10-09T17:47:52.083Z

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

dominicm 2020-10-09T18:57:06.084Z

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