To put it another way, paraphrasing a developer I've worked with:

Front-End Coder: "So, we bring up the table, drop it to this array..."

Me: "Wait, the entire table?"

FEC: "Yep, then we do our bubble search..."

Me: "Why not run a proc?"

FEC: "Because we have the array and can do it there."

Me: "But SQL was built for this."

FEC: "Yeah, but I know arrays, and we have the array. We're not changing now."

Me: ... ... "I was hired why?"

FEC: "To help speed up getting data from the database. Help me figure out how to feed the array faster."

Me: :blink: :crying:

Coders and DBAs are fellows in the system. They know how to obfuscate and encrypt IIS. I know how to properly secure a SQL Server. My desired knowledge ends in knowing what they can/can't do at a high level. Most coders are the same way in the other direction.

I know a few people who can switch mindsets well enough between iterative coding and set coding, but they are few. The majority of coders cannot think in sets... and that goes vice versa. It's a mental habit, one you train yourself in. Most people, even incredibly intelligent ones, do not switch between the mindsets easily. That's merely covering one of your seven bullets. All seven can be like that.

The primer you're asking for would be more useful as a simple checklist for those lone wolf front end coders, something to double check when they can use it. The majority of untrained, un-interested coders are better off (shoot me now) using the SQL Server as a back end file system. At the least, they'll be able to troubleshoot their own mess effeciently. Eventually, they'll decide to learn it, and start looking up the necessary documentation to do so. Any one of the points above requires a solid amount of knowledge. You're not going to cover any of those in a few pages of a primer. Not well, anyway.