Interesting thought, Jay!

Back when I was running my own Internet Marketing company, I wore all hats -- software developer, database architect, database admin, sysadmin. I was forced to learn how to optimize MySQL operationally as traffic pounded my sites. Got real imtimate with the my.cnf file, replication, and all sorts of other details that I "never needed to know" as a pure developer.

Ironically, I am currently learning how to be an Oracle DBA. But my role there will be quite limited -- merely a "DBA", not a developer, as Oracle is required by a third-party tool we are using at my shop.

But on the MySQL side, I am doing it all -- schema design, database administration, and sysadmin stuff. I am having to understand how the entire network constellation of servers interact with the application and how that interacts with the databases to diagnose site outages, site latency issues, and the like. It is quite complex, and quite a challenge. I am actually relying on my knowledge of complexity and queuing theory in my attempts to understand the network dynamics. Even though I am not solving equations per se, the understanding of the mathematics actually helps.

If you want to be a boring Oracle DBA, you have to work in a large bureaucratic establishment. There, you can rest in your pride that the Peter Principle can dominate your existence. But in a small shop, you really need to be more flexible and wear many hats; there is just no getting around that.

Also intriguing is that Oracle DBAs tend to see themselves (IMHO) as more of a strict DBA than MySQL DBAs, who tend to come up through a developer mindset, get slammed with administration requests and must learn through trail and error...

It's rare you hear a MySQL DBA say "all I do is administer MySQL databases", whereas I think there is an inherent pride within the Oracle DBA camp that they are strictly Oracle DBAs...

Just a thought,

Jay

Nail, meet Hammer.

I was waxing poetic on this very topic the other day with a co-worker. Our developers are pushing to implement certain functionality across our customer base. I keep shooting them down by asking simple questions like "Does it conform to these standards?", "How do we monitor for success and failure?" and "What happens when...?" to which they step back, scratch their heads and go back to their desks.

The same goes for DBAs. I know some developer DBAs who can write SQL and stored procedures in their sleep but forget their their local tnsnames.ora file was pointed to a production database when they ran the install script which starts out with a "DROP DATABASE foo;" statement. I can setup MySQL databases in less than 5 minutes, manage growth from 100 megs to 100 gigs without breaking a sweat...but I still have trouble writing JOINs.

There is a great divide between Administrator and Developer (systems and database.) We all cross each others boundaries from time to time and that's a good thing. The important thing to do is humble yourself when you cross over so you don't end up with foot-in-mouth disease.

I certainly agree that DBA has become a much more flexible term than sysadmin... I'm labeled the DBA at my company, which puts me half on one side and half on the other. For one, I'm the developer people come to when they have MySQL programming questions (complex queries, weird errors, etc), plus I handle all the GRANTs and such. And largely that's what a small company needs. I'd hesitate to call myself a genuine administrator, though, largely because I'm not much as far as configuration goes. I tend to learn by necessity, and the fact is that none of our sites really get enough traffic to warrant delving into configuration and optimization that much when my time is more often spent on actual web application development. For me, DBA isn't really my job, it's just one more task tacked onto the stuff I already do.

That said, I've got the MySQL certification study guide and am slowly trudging through it, so maybe I'll land in the true administrator category one of these days.