Developers: sometimes you just gotta trust the DBA

At this week’s Customer Advisory Board at Quest, I’ve had a great time sharing war stories with other database administrators.  One theme keeps popping up again and again: developers don’t trust DBAs and seem to refuse to take the DBA’s word for anything.  It seems that developers just want to keep learning things the hard way.

Case in point: a developer wants to loop through all string fields in every database in the shop looking for secure information.  They’re after things like social security numbers, credit card numbers, bank account numbers and so forth.  They want to check the contents of every char/varchar/nchar/nvarchar field in every table, look at the top X records, and check the string contents to see if it matches known text patterns.

In theory, this could be solved by a stored procedure.

In practice, a stored proc would be a bad idea.  SQL Server isn’t particularly good at string processing, and a query like this will instantly push the CPU to 100%, thereby severely slowing down other queries on the box.  Plus, large databases like SAP can have tens or hundreds of thousands of string fields, and storing the results will take gigs of memory and/or TempDB space on a large BI/BW data warehouse.

The DBA involved has repeatedly recommended against the stored proc approach, but the developer still wants to build one, saying he’s Googled for ways to do it and he’s getting some good leads.  At what point  the DBA will sit back and say, “You know what, go for it, because when your stored proc takes down a production box, I’ll be all too happy to explain whose code did it.”

Another case involved developers who want to store completely unstructured XML data inside the database as text fields, and want to parse through that XML data when searching millions of records for matching attributes.  The XML format will be extremely flexible, but when storing it as text, it’s just not going to perform.  The developers see that as a SQL Server performance problem, when in reality it’s a bad design that won’t scale.

We spent some time tonight at the CAB talking about where the DBA draws that line – where he gives up trying to protect the developer and just gives the developer enough rope to hang themselves.  It’s an interesting challenge politically, but the moral of the story is this: developers out there, if your DBA keeps recommending that you do something, and all of a sudden one day he caves in and sees things your way, be careful.  You might be in for a rocky ride.

Previous Post
I have big hands
Next Post
Free SQL Server tools and utilities
Menu
{"cart_token":"","hash":"","cart_data":""}