The time I accidentally spent a year combatting fraud

While I agree there's a place for business rules (the app), properly enforcing referential integrity and uniqueness can now easily be done in both - and I trust PostgreSQL more.

Not stored procedures, or triggers, or anything like that... Just a giant plugin loaded when the DB starts that provides business specific functions that can be called by the client instead of SQL queries (think "CreateAccount" or "GetFooDetails").

Oh, and probably 50% of the columns are giant JSON objects.

It's.... interesting.

Hours to days of data cleanup work that could have been bypassed by setting a simple unique index.

A couple years ago, the company I was working at had a dedicated team just for JIRA (and other workflow mgmt systems).

They were looking for some people to fill out the team so I asked my SRE friends if they knew any good JIRA people.

I was surprised that the #1 answer was "Dedicated JIRA people? Why don't you just have someone do it from your team. JIRA isn't that hard."

This immediately made me think of the "Why do we even need DBAs? It's all ORM anyway." Which of course leads to "Why is the DB so slow?" etc etc

I thought that was a bad scenario till a friend was telling me at their current employer (which uses a lot of databases) they routinely ask "Is anyone here the DBA?" and the answer is "What's a DBA??"

This used to be quite common back in the day. In a sense the database was thought of as the application platform so the reasoning was to move business logic as close to the data as possible.

Performance was also a big driver since the DB was often the most high-powered server / cluster in the datacenter. An argument I heard was that by pushing logic into the DB via stored procedures and the like, you would get better performance that way vs. pulling a result set into application memory and then dealing with it there.

Note that I am not rendering a qualitative judgment on any of this, just sharing my experience. :)

Great reads! Thank you for sharing.

I just wanted to say - I have been there, and I feel you. When I read that, it was visceral - took me right back to the couple times I've had those moments. Good on you for keeping on, and using what the experience offered to make things better afterwards.

The fact that the impact is generic, and you can not be sure about that the candidate's actions were the true cause?

In this case would a more specific claim with a more solid reasoning help?

Or are you dismissing all claims of potential positive impacts?

I'm on a team that rebuild a sales/onboarding funnel. I was told it resulted in 5 million in additional revenue generated this year. I'll use that number on my resume at some point. But mostly because I don't have a more useful number to use.

If you ask me I can share all about how and why we build it which is probably what you actually care about, right? 5 mill might be a lot at a small company or almost nothing at a large company so $ and % are pretty much irrelevant. It's the process of building that you would actually care about, no?

Typically, these rules are not what people mean when they say they use their DB as a dumb data store. What they mean is:

- your "schema" is not that important. Sure, you spend a lot of time modeling data in such a way that your application always handles valid data. Once that's done, your DB is "just" a store for that data.

- data integrity is enforced before data reaches the DB. pks/fks are mostly there to ensure fast queries.

The idea is that data in your system should be in a sane state way before it reaches the database, and once it's sane, making more controls at DB level is just a layer of administrative checks done in a language that is not really well-suited for that.

https://news.ycombinator.com/item?id=36030033

Stories like this one are a reminder not to pour your life into your work. The sacrifices don't always pay off.

You're using an ORM to query a record and as you're looping through the results you need to reference something in an association.

You get one query that returns 50 results, then loop through those 50 results and trigger a one off query for every result in the loop. Now you're executing 51 queries instead of the original one.

Now imagine you go another level deep or have multiple results from each of those sub queries to loop through. It can get out of control. In Rails and a lot of ORM's you can typically solve these by eager loading the nested associations with very little effort. The rest of the code will work the same but behind the scenes only 1 additional query will be triggered to fetch the records from the association.

I once took a Python API with SQL Alchemy and took 30% of the speed by adding an eager load instruction to a query. Python profiling showed a lot of time in the ORM & database, then turning on SQL logging made the issue obvious.

Still feels like it should be called the "1 + N" problem tho. The 1 query happens first, then the N queries afterwards.

ORMs are notorious for making it easy to write this anti-pattern without noticing, though you can do it in raw SQL too. ORMs usually also have various helpers for eager loading of associations to try and prevent it. In raw SQL, it's on you to notice that you're doing it and write the correct query.

It was crazy driving home from work, getting a call that a phishing email went out when they clearly waited until we wouldn't be around to take it down. Then getting home, opening up the computer, making Skype calls to an ISP in South Africa to notify their abuse teams for the take down.

"Swimming", "running", "batting" come from "swim", "run", and "bat", respectively. The present participle form doubles the consonant at the end of the word "as a rule" I was told. A single consonant would mean that there is a silent "e" at the end of the word which suggests a preceding long vowel (e.g., cure -> curing, compete -> competing, combate -> combating).

Anyway, it's because nobody follows rules when writing and speaking English and as long as the other person understood your meaning, your grammar was correct.

Apparently, both are correct.

https://writingtips.org/combating-or-combatting/