this is the year 2020, Why do fuck do people still add business logic to the database?

Do you mind giving an example?

@sbiewald, for example, carrying out calculations in the DB

Stored function?

DB to rule them all, I suppose.
Imagine they have all their clients connect to... DATABASE - and CRUD data directly. Much efficient, right?
No? You can't say "No" to database calculations or you aren't real dev 😂

(it was sarcasm)

Aggregation calculations can be best done in db

I argue this with our DBAs. Their definition of 'business logic' differs from most people.

Ex. If there are any 'if' statements in a stored proc, DBAs consider that potential 'business logic' in their database.

I would consider 'business logic' in the database if the stored procedure raises an exception 'You entered an incorrect value. Press any key to continue'. Yes, we've had that.

But 'soft' data integrity checks (making sure a value is not null, within a range, etc), should be 100% OK to do in the db.

I recently started to learn about databases in school and how you're supposed to have "Referential Integrity" and "No redundancy".

But what does it really mean to have buisness calculations in a DB , and why does it make it less efficient? Just wondering for my curiousity.

And is this written in SQL?

@Entity-01000101 > "what does it really mean to have buisness calculations in a DB"

A real life example we have is in our order system where we have 'business rules' in the database that makes sure there is enough inventory at the moment of invoice creation. A fair number of DBAs here have 'cut their teeth' trying to move that logic into the service tier, but because many internal/external/political factors, the (SQL) code I wrote over 15 years ago is still in production today.

Every time someone (DBA, overzealous dev mgr, etc) say/brag "We've finally moved this business logic out of the database!", then a random Saturday morning at 3:00AM we're alerted to inventory out of balance issues, fingers start pointing back-n-forth, a VP threatens "heads will roll if this is not fixed right now!!!", then the 'old' process is put back into place. Right or wrong, the simple "Customer wants 3, do we have 3?" check works every time.

@PaperTrail

Ahhhhhhh ok, so you're over here trying to implement the simple methods that "Just work" and others are trying to "Modernize" everything in the programming. I get you.

Lmao , Do we have three?

@Entity-01000101 > "Lmao , Do we have three?"

We're in the shooting sports industry, so, no.

People are buying guns n ammo like there could be a President elected that would take their guns away.

Remember the Ferengi Rule of Acquisition #34, War is good for business. I hope November 4th and beyond rule # 35 plays out (Peace is good for business).

Business logic is - as the thread shows - very ambigious.

Let's make it quick:

- no cursors, triggers, behaviourism's in databases

- don't split brain: eg. if you have rounding of currencies, conversion of units, etc. decide which system is dominant. That system must handle that process - no if's, but's or maybe's. In most cases it should be the software.

When software and database are involved and one side has errors, it affects the other side in almost all cases. Leading to a pretty fucked up situation - you'll need to fix software, validate all data in database, fix it and revalidate [since DB might generate faulty data, too]

So... Decide which part is responsible for data generation and validation.

- statistic / aggregations / "data blending and bending"

Database makes sense here.
Most people think that (previous point) this has to be on the dominant side, too.

That's half true. The previous part is about who generates and validates the _base_ data. Statistics / aggregations / ... should never modify base data - they should live far away from the base data.

Storage is cheap. Defucking tons of data and maybe having legal issues (wrong taxes, leaked data, pissed customers) isn't.