Business logic in the fricking database.

1000+ line SQL stored procedures.

What the actual fuck?! 👿

Burn it before it lays egg!

Welcome to the real world 🙂

Will probably won't be the last time you see something like this, if you have to work with customer's databases

Seen it more times than I care to count, pisses me off every time. #hate debugging mountains of SQL.

New to devRant so figure it's high time to vent about it. :D

@civel
This was my last company. I left quickly!

So many companies do this. "Yeah, just write a sproc...". Complex logic has no business being put in a stored procedure.

Well I don't like it either, but we once had to do it. It's a web based POS solution and it was essential that the average time / customer is as low as possible. Even half a second makes a huge impact. The transactions happens in a short period of time in bursts. To create a transaction we needed to process a shitload of records. It made sense to put that in the DB. Multiple 300 lines+ SPs. We had to make our own tool to maintain and version the schema and generate update scripts as we modify it. Of course, normally you shouldn't do it...

Nobody told you huh...

Welcome to the wonderful world of custom corporate software, where SQL is king.

sometimes db does all logic much faster than your nested php loops over temp arrays with lot of ifs. especially when db size counts in terabytes

@MaxDeepfield Yeah, I'm one of those people who occasionally write these procedures. I hate every minute spent coding and maintaining those, but fu** are they fast, if written well.

Especially if your have dedicated database servers, the difference in performance to "normal" code can be staggering (and that already assumes you are bulking your SQL queries appropriately).

Even field validation, I believe? 😏