Let the DB Handle It

Perhaps I'm pointing out the obvious, but software developers don't always seem to experience data the same way that, say, a DBA or a BI developer does.

I'm not saying that they don't process in rows and columns, or that they all have Dyscalculia or something.  I'm saying that I frequently detect a reluctance in developers to let the database handle it.  I theorize that this issue can come from a number of possible sources, but is usually a symptom of childhood trauma related to set-based math...

The rationale provided is often one that I consider an artificial barrier in this day and age, which is the old saw that "business logic can't go in the database".  In my decade-plus of experience maintaining, designing and building business software, most of the databases I've encountered have been fairly inextricable from their front-end line-of-business apps from the beginning.  And most of these apps are not going, say, make a switch between platforms or OS's without a wholesale rewrite of the code, anyway.  So using PL/SQL packages or a set of T-SQL stored procs to help encapsulate logic is not a very serious crime.  As long as it's documented, of course.  Also, the best iron in the whole solution always goes to the DB machine. Why not leverage it to accomplish the work of the application? Save some clock and RAM utilization in your web farm and let the database do it.

Another scenario is when the RDBMS is considered a "Mystery Hole," where strange, nigh-impossible things happen in the darkness and hum of the server closet.  I find this understandable enough from developers. I don't see much evidence that good data theory is being imparted on software dev students.  And SQL itself, as a language, operates in a different paradigm from any procedural or OO language, and it requires those nasty set math skills to become accomplished with it.  Advanced SQL techniques do take years to learn, and even to recognize when they can be brought to bear. 
That said, a Pivot operation takes a lot more Java or C# code to implement than it does SQL.  And frankly, being good with SQL means bever having to write a loop. 
It makes sense (to the point of being mandatory, IMHO) for software developers to learn how data works, how SQL and databases work, and when you can leverage them for processing power by letting the database handle it.

A variation on this "Mystery Hole" thing is where it's not about being unfamiliar with the DB environment, but instead it's all about control.  The developer simply can't have any of the logic NOT in code that she has her hands in.  Maybe I'm wrong but, on a big enough project, that way lies madness, methinks.  And again, it fails to heed the wisdom of "rendering unto Caesar that which is Caesar's."  For certain tasks/functions, it's often more expedient and design-time and run time to just let the DB handle it.

Now, I have encountered on many occasions scenes where DBAs and application developers are at odds.  Usually over who gets to do what in whose environment.  In many of these, I wouldn't be surprised to find one of the syndromes above involved.  But there are many times when the obstinacy and regimentation of a DBA will make developers want to punch them dead in the face rather than get involved in DB coding.   So it's certainly a two-way street, and I'm not going to applaud overly-controlling DBAs any more than overly-controlling Developers.  Clearly both parties are on the same team, and should be cooperating to solve the business goals they support, yes?  Rather than playing parochial games over fictitious territories?

Maybe the fact that I'm partial to such compromise (or even averse to conflict) is why I ended up in the BI world.  But as an application developer I always felt it was critical to have insight into the DB layer in order to be a well-rounded architect-level software professional. And if you could get it, working knowledge of the the network/infrastructure layer, too. 

But let's not get ahead of ourselves.  I suppose it's enough to expect that software developers know when to -- well, you know.