Comments on: Who Should Write Database Code?

By: Atif Shehzad

Atif Shehzad — Wed, 18 Nov 2009 15:51:54 +0000

I found it not efficient to let the developers code for DB objects. Functions and procedures with simple logic and with less pitfalls should be coded by developers, and DBA should take a look for optimization, before running on production server. And critical/complicated objects should be coded by DBA. I think it is a very plus point for DBA to be capable of optimized coding the required objects.

By: Stewart Blacklock

Stewart Blacklock — Tue, 24 Mar 2009 14:57:14 +0000

Rob – The environment I learned and went from an application developer to an experienced database developer was a partnership. Application developers would write their SQL. The Application DBA would monitor production queries and would find problem ones. As he found bad queries, he would point out the issues to the developer and help them improve the queries. Expectation is that application developers would improve over time (which did occur)
Yes – this meant that production always had a few issues and their always is an element of rework, but it was much more scalable than having the DBA having to write them all by scratch.
On my current project we do something similar where I’m now the mentor. We are finding stored procedures that take 30 minutes…that I’ve been able to re-write down to 1-3 seconds. If I just do the re-writes though, next code that comes along will have problems…so I have to force myself to step back and get the team to understand how to do things better themselves.

By: Sankar Reddy

Sankar Reddy — Mon, 23 Mar 2009 04:36:41 +0000

Over the years I have seen horrible practices not only by application developers but by some experienced (over 12+ years) database developers too. It comes down to who has better understanding of database concepts than just a title of database developer/dba.

The other issue we see is, corporations tend to throw hardware on a problem that could be fixed by carefully choosing the resources, spending more time during the recruitment process.

Sharing some horrible experiences.
1) Storing int values in varchar (7). After 4 years and building 5-8 different systems on top of this data model and running of loan numbers after 9.9 million, this system was scrapped to for a better model. There were other reasons also to move to a better model.
2) One table had 3 separate triggers, few of them calling cursors which had business logic per state and this code was called repeatedly.
3) 64 bit, 32 Gig, 8 core box with 40 Gigs of data runs with 60-80% cpu usage. 90 % of the tables were fragmented with over 70-100% fragmentation.
4) Defragmenting indexes once a month or still stopping the whole enterprise for 2-3 hours to defragment indexes on SQL 2K5 box. Online Indexing for them is considered bad or less efficient.
5) Performance Tuning means dropping & re-creating the SP after every 30/60 minutes.
6) Its not important to run dbcc checkdb; it takes 8-10 hours and we don’t have time is their comment. These guys should get a whipping from Paul Randal.
7) Updating statistics manually is considered bad practice.

The problem is some corporations don’t employ a (good) database architect and these so called experienced database developers/dba’s were hired by managers who had little knowledge of dbms systems. Corporations should spend more time at the recruitment process to filter out people like them who boast themselves as gurus. I was called bad sport for calling out issues like above. And my colleagues didn’t talk with me for several months until they were shown the door.

By: Jeremiah Peschka

Jeremiah Peschka — Sun, 22 Mar 2009 14:50:02 +0000

Personally, I think that a specialized Database Developer should be handling the job if scalability or performance are at all concerns. Why? Well, for starters, I am one.

Besides a shameless personal plug, I also think that a dedicated database developer is generally going to understand the data that is present in any given application and will also understand the business requirements of the application developers and can usually work with them to create a quick, scalable data access plan that is flexible enough to meet their needs while still staying performant.