Michael Flanakin's Web Log

I think your assessment of the importance of a developer to a dba is that case only in a software development company. In a company dependent on processes and systems, which is almost everyone else, the database availability, protection, and efficiency is paramount. Think manufacturers, Banks, brokerages, airlines, etc, etc. If the database goes down, it can be tens of thousands of $ an hour or more. And lots of upset customers.

And data volume is growing exponentially, and will for the foreseeable future. Imagine all the data RFID adoption will produce, deep specialists will be required to know how to deal with it. So, the DBA isn't going anywhere, as a matter of fact they will be in much more demand. As a saying I heard once said, developers come and go, applications come and go, but the database remains :) Very true!

Yes, you're right. I was referring to software development companies. And, as I mentioned, "there are always situations where you might need the latter." I faulted in only covering the scope of software, however.

At the same time that you say "...the database remains," let me remind you of the large XML initiative. I've seen a lot of small databases converted to XML because of its ease of use and programmability. I'm not saying XML is the answer, I'm just saying that there will always be new technologies that will replace old ones. So, databases may not always be there. And, I wouldn't bank on that - you never know where things will be in 10 years.

But, again, you are right. I was understating the importance of the DBA, and I apologize for that.

You have been Taken Out! Comments about your posting in this link. Thanks!

And what do you think will happen with the next version of SQL Server? Even now, the DBA at one of my client companies has not so much as a clue what my SQL SP code does. Not a hint. He is a nice enough guy, but he is not a programmer, and even simple procedural logic (and certainly complex SQL Logic) is completely past him. Add in CLR code in the database, and what you will need in a DBA role is not what is now considered a DBA, but rather a Database savy programmer.

Personally, I don't like the idea of having code in the database, whether it be T*SQL, PL/SQL, Java, or .NET code. I'd rather keep it with the applicaiton - with the rest of the code.

Now, despite this ideal, I know that there are performance and other issues that might drive someone to using the database for these things. Those just need to be analyzed to determine the worth. Do you want portability or performance? (Sounds like a Java vs. .NET question) But, I do like the idea of having a "real" language in the database for when you do need to get some work done.

Hmm I see I am outnumbered by software developers.. I've been one myself, so give me a little credit for perspective, after all I manage a group of DBAs now :)

The next version of SQL has high end features currently only available in Oracle and DB2, including partitioning, materialized views, ETL functions, and other features supporting very large installations. Believe it or not, these are things requiring a pretty deep level of specialization, not something you can pick up in a weekend... Add in the OLAP capabilities and you really have room for several areas of specialization, which is already happening.

In my job I have been involved with supporting installations of multiple applications written by very talented developers, but there have been numerous times I or someone on my team has had to provide technical feedback on quickly written, but poorly planned queries against the database. Invariably, the develeopment companies did not have a DBA on staff, and it had a negative impact on their application performance to the point that made it unscalable, or even unusable in a production environment.

About XML - sure, that will work fine for extremely small datasets. What do you do with 5 million records though? with multiple joins? with triggers? how about 100 million? or what if more than one client needs to access the data? I'm talking of the data store/engine here, not the transport method... of course most dbs support XML interfaces to retreive the data - all of the storage and indexing is handled by the database though.

Good DBAs earn their pay I assure you, but like developers, there's plenty of wanna-bes too, it's no different.

I agree 100%. One thing that we have here, is a Database Support Team. Currently, they only support Oracle, but at least the idea and facility is there and can be expanded upon. I like this idea because then, once you get something up, you won't always need a full-time DBA. This team can help people setup their database and can bring up issues with different approaches and suggest better ones, when appropriate.

I like the idea of having specialized teams. Teams that can focus on their skill and use that to help better educate developers on those skills.

Oh, and I have to say something about the developers with bad database/SQL skills...OMG!!! That annoys the crap out of me. I admit, there are a lot of things that I don't know, but I can manage my way around both SQL Server and Oracle databases. My first real "programming" job was based on Oracle, so I got a lot of SQL training from that. I've been able to expand upon that foundation, but there is definitely room for improvement; and, I will always be asking for DBA opinions to help educate myself.